Проверка и обнаружение SQL-инъекций в PHP - PullRequest
5 голосов
/ 26 июня 2011

Я новичок в PHP и пока не знаю, как это работает.

  1. Если я использую mysqli_real_escape_string() и параметризую каждую переменную в запросе SQL, могу ли я сэкономить на выполнении проверки с помощью is_numeric() и т. Д .?

  2. Каков наилучший способ создания системы обнаружения впрыска? Просто подтвердите ввод пользователя с помощью регулярных выражений и сохраните его в базе данных?

Ответы [ 5 ]

4 голосов
/ 26 июня 2011

Параметризации вашего запроса достаточно, вам больше ничего не нужно. Вы будете вводить то, что они «вводят», в виде строки, и в базе данных нет ничего особенно неправильного с sql ... Я подозреваю, что база данных SO полна SQL;)

3 голосов
/ 26 июня 2011

Экранирование значения для MySQL просто добавляет обратную косую черту перед следующими символами: NULL \n \r \ ' " и 0x1A. Больше ничего не делает.

«Экранированное» значение не является магически безопасным для использования в SQL. Экранирование предотвращает неправильную интерпретацию специальных символов (например, кавычек). Но если вы вставите экранированное значение в SQL-запрос, не заключая его в кавычки, то вы полностью упустили этот момент, и вы не более безопасны, чем в противном случае.

Помните, что процедура безопасности - , кавычка и побег . Вы всегда должны использовать эти два вместе, так как ни один не безопасен без другого.

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

Но что еще более важно:

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

Параметризованные запросы являются решением, поскольку они надежно отделяют данные от управляющей структуры. Параметризованные запросы возможны в mysqli с помощью prepare () , за которым следует bind_param () . При использовании этого метода экранирование не требуется, , и вы можете быть уверены, что абсолютно защищены от атак SQL-инъекцией.

2 голосов
/ 26 июня 2011

Даже если вы защитили свои переменные от внедрения с помощью параметризованного запроса или mysql_real_escape_string() (не mysql_escape_string()), вы все равно должны проверить их на стороне сервера, чтобы убедиться, что они соответствуют ожидаемому типу ввода.Таким образом, если они этого не делают, вы можете вернуть сообщение об ошибке своему пользователю с просьбой повторить эти поля формы.

Если вы используете параметризованный запрос, такой как предложенный MySQLi, в качестве подготовленного оператора, вам также не нужно экранировать строки.Однако, если вы не используете параметризованный запрос, важно вызывать mysql_real_escape_string() для каждого входного параметра, полученного PHP.

1 голос
/ 26 июня 2011

Это хороший вопрос, и я думаю, что одним из лучших способов избежать внедрения SQL-кода является изучение правильного использования подготовленных операторов

Это действительно поможет безопасности вашего приложения.

0 голосов
/ 26 июня 2011

Проблема с внедрением sql заключается в том, что пользователь вставляет данные SQL в команду и не проверяет соответствие этих данных вашим бизнес-правилам.

Проверка того, что все пользовательские данные передаются через mysqli_real_escape_string или используются подготовленные операторы, - лучший способ избежать проблем.

...