Действительно ли 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() [is] небезопасен, когда используется SET NAMES».

Его объяснение, from his blog:

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

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

Он упоминает, что UTF-8 является безопасным, хотя.

Answer 2

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

Answer 3

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

См:

• MySQL bug #8303: Строковые литералы с многобайтными символов, содержащих \ являются lexed неправильно
• 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, который отключает обратную косую черту в качестве символа escape-котировки.

Answer 4

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

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

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

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