Я использую mysql_real_escape_string до SQL INSERT, но затем мне приходится применять штрихи к моим полученным данным. Это нормально?

Question

Я не эксперт по PHP / SQL, и я обнаружил, что мне пришлось применить mysql_real_escape_string для защиты моих SQL INSERTS.

Я сделал функцию, используя несколько советов, найденных в сети, вот она:

function secure($string)
{
if(is_numeric($string)) 
    { $string = intval($string); }
    elseif (is_array($string)) 
    {
        foreach ($string as $key => $value) {
            $string[$key] = secure($value);
        }
    } 
    else if ($string === null) 
    {
        $string = 'NULL';
    }
    elseif (is_bool($string)) 
    {
        $string = $string ? 1 : 0;
    } 
    else 
    {
        if (get_magic_quotes_gpc()) { $value = stripslashes($string); } 
        $string = mysql_real_escape_string($string);
        $string = addcslashes($string, '%_');
    }
    return $string;
}

Дело в том, что когда я смотрю на содержимое таблиц, оно содержит обратную косую черту. И затем, по логике вещей, когда я получаю данные, мне нужно применить полоску к ним, чтобы убрать эту обратную косую черту.

Магические кавычки отключены.

ВОПРОС 1) Теперь я думаю, что хотя я использую mysql_real_escape_string для защиты своих данных перед вставкой SQL, обратные косые черты не должны появляться в моем контенте? Вы можете это подтвердить?

ВОПРОС 2) Если это не нормально, почему эти обратные косые черты появляются в моем контенте и поиске phpMyAdmin? Что я сделал не так?

ВОПРОС 3) У меня есть предположение, что mysql_real_escape_string может применяться дважды, не так ли? Если так, что может быть функцией, предотвращающей многократное применение mysql_real_escape_string к одной и той же строке, что приводит к множеству \\ к одному и тому же экранируемому символу?

Большое спасибо заранее за ваши отзывы, ребята!

Answer 1

о, какая бессмысленная функция. Я знаю, что это не твоя вина, а те, кто написал это в своих глупых статьях и ответах.

Избавьтесь от него и используйте только mysql_real_escape_string для экранирования строк .

ты все перепутал.

• во-первых, в функции экранирования базы данных не должно присутствовать никаких волшебных кавычек.
  если вы хотите избавиться от магических кавычек, делайте это централизованно, на самом верху ВСЕХ ваших скриптов, независимо от того, имеют ли они дело с базой данных или нет.

• большинство проверок в этой функции бесполезны. is_bool например. PHP будет конвертировать его таким же образом, нет необходимости писать код для этого.

• Как и связанный с этим побег, это совершенно отдельный вопрос и не имеет ничего общего с безопасностью.

• - числовая проверка совершенно бесполезна, так как ничего не поможет.

Также обратите внимание , что экранирование строк не имеет ничего общего с безопасностью.
Я просто правило синтаксиса - все строки должны быть экранированы. Независимо от его происхождения или каких-либо других вещей. Просто строгое правило: каждый раз, когда вы помещаете строку в запрос, она должна быть заключена в кавычки и экранирована. (И, конечно, если вы только экранируете ее, но не в кавычках, это ничего не поможет)

И только когда мы говорим о других частях запроса, речь идет о проблеме внедрения SQL. Чтобы узнать полное руководство по этому вопросу, обратитесь к моему более раннему ответу: В PHP при отправке строк в базу данных мне следует позаботиться о недопустимых символах с помощью htmlspecialchars () или использовать регулярное выражение?

Answer 2

Ваша полоса $string сохранена в неправильной переменной $value вместо $string:

if (get_magic_quotes_gpc()) { $value = stripslashes($string); } 

должно быть

if (get_magic_quotes_gpc()) { $string = stripslashes($string); }

Answer 3

Полное удаление надстроек из всего вашего кода.Это основная причина для вставки слешей в базу данных.

function escape($string) {
    if (get_magic_quotes_gpc()) {
        $string = stripslashes($string);    
    }
    return mysql_real_escape_string($string); 
}

Всегда проверяйте, включен ли magic_quotes_gpc, выполняет ли он удаление строк и экранирует данные.t использует addlashes "

Когда он входит в базу данных, '\' удаляется.

Answer 4

Вы уверены, что не вызываете mysql_real_escape_string более одного раза, каждый раз, когда вы вызываете его с помощью экранируемых символов, вы в конечном итоге добавляете все больше и больше слешей. Вы хотите позвонить только один раз. Кроме того, почему вы также вызываете addcslashes? mysql_real_escape_string должно быть достаточно. Если вы вызываете его только один раз, вам никогда не придется вызывать полоски на данных после извлечения их из базы данных.

Вы не можете точно сказать, применяется ли mysql_real_escape_string более одного раза, я бы посоветовал вернуться и перечитать ваш код внимательно, попробуйте отладочную печать значений непосредственно перед тем, как они будут вставлены в БД, чтобы увидеть, выглядят ли они «чрезмерно полоснул.

Между прочим, если вы используете подготовленные операторы (например, через mysqli), вам не нужно экранировать строки, движок БД сделает это за вас, это тоже может быть проблемой.