Защищает ли mysql_real_escape_string () ПОЛНОСТЬЮ от внедрения SQL?

Question

В http://www.justinshattuck.com/2007/01/18/mysql-injection-cheat-sheet/?akst_action=share-this есть раздел, в котором утверждается, что вы можете обойти mysql_real_escape_string с определенными азиатскими кодировками символов

Обход mysql_real_escape_string () с BIG5 или GBK

"струна для инъекций"
に 関 す る 追加 情報:

вышеприведенные символы китайские Big5

Это правда? И если да, то как бы вы защитили свой веб-сайт от этого, если бы у вас не было доступа к подготовленным заявлениям?

Answer 1

По словам Стефана Эссера, "mysql_real_escape_string() [небезопасно], когда используется SET NAMES."

Его объяснение, из его блога :

SET NAMES обычно используется для переключения кодировки с того, что используется по умолчанию, на то, что требуется приложению. Это сделано так, что mysql_real_escape_string не знает об этом. Это означает, что если вы переключитесь на какую-то многобайтовую кодировку, которая разрешает обратную косую черту как 2-й, 3-й, 4-й ... байт, вы столкнетесь с проблемой, потому что mysql_real_escape_string не сбрасывается правильно. UTF-8 безопасен ...

Безопасный способ изменить кодировку - mysql_set_charset, но он доступен только в новых версиях PHP

Однако он упоминает, что UTF-8 безопасен.

Answer 2

Это ошибка сервера MySQL, которая, как сообщается, была исправлена ​​еще в мае 2006 года.

См:

• MySQL bug # 8303 : Строковые литералы с многобайтовыми символами, содержащими \, неправильно лексированы
• MySQL Bug # 8317 : средство ввода набора символов в запросе не может переопределить набор символов соединения
• MySQL Bug # 8378 : строка неверно экранирована с набором символов клиента 'gbk'
• MySQL 5.1.11 changelog .

Ошибка была исправлена ​​в MySQL 4.1.20, 5.0.22, 5.1.11.

Если вы используете 4.1.x, 5.0.x или 5.1.x, убедитесь, что вы обновили хотя бы меньшие номера ревизии.

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

Answer 3

Я почти уверен, что он не будет работать, только если вы используете SQL для изменения кодировки символов.

Answer 4

Как показали другие, mysql_real_escape_string() можно обойти в неясных крайних случаях . Это одна из известных стратегий обхода логики выхода, но могут быть и другие неизвестные уязвимости, которые еще не были обнаружены.

Простой и эффективный способ предотвратить внедрение SQL в PHP - это использовать подготовленные операторы , где вы можете, и очень строгий белый список, где вы можете т.

Подготовленные операторы, когда они фактически используются и не эмулируются драйвером PDO, надежно защищены (по крайней мере, в отношении внедрения SQL), поскольку они решают фундаментальную проблему безопасности приложения: они разделяют данные из инструкций , которые оперируют данными. Они отправляются в отдельных пакетах; параметризованные значения никогда не могут испортить строку запроса.

Это 2015 год. Не убегай и не соединяй больше. Вы все равно должны проверять свои входные данные в соответствии с логикой приложения (и бизнес-логики), а просто использовать подготовленные утверждения.