Mysql_real_escape_string () не работает? - PullRequest
13 голосов
/ 13 марта 2011

Некоторые люди считают, что mysql_real_escape_string() имеет некоторые недостатки и не может защитить ваш запрос, даже если он используется должным образом.
В качестве доказательства можно привести окаменелые изделия .

Итак, вопросis: действительно ли mysql [i] _real escape_string () совершенно неприемлемо?
Или все еще возможно использовать эту функцию для создания собственного типа подготовленных операторов?

С кодом подтверждения, пожалуйста.

Ответы [ 3 ]

24 голосов
/ 13 марта 2011

Из функции MySQL C API mysql_real_escape_string описание :

Если вам нужно изменить набор символов соединения, вы должны использовать функцию mysql_set_character_set() вместо выполнения оператора SET NAMES (или SET CHARACTER SET). mysql_set_character_set() работает как SET NAMES, но также влияет на набор символов, используемый mysql_real_escape_string(), что не SET NAMES.

Так что не используйте SET NAMES / SET CHARACTER SET, а PHP * mysql_set_charset, чтобы изменить кодировку, так как это аналог mysql_set_character_set MySQL (см. исходный код * 1030) * / внутр / MySQL / php_mysql.c ).

7 голосов
/ 13 марта 2011

Однако даже при использовании устаревшего кода и старых версий сервера уязвимость может быть активирована только в том случае, если набор символов соединения с базой данных изменяется с однобайтового, такого как Latin-1, на многобайтовый, который допускает значение 0x5c ( ASCII одинарная кавычка) во втором или последующем байте многобайтового символа.

В частности, UTF-8 не позволяет этого, в отличие от более старых азиатских кодировок, таких как GBK и SJIS. Поэтому, если ваше приложение не изменяет набор символов подключения или меняет его только на UTF-8 или однобайтовые, например Latin-n, вы защищены от этого эксплойта.

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

3 голосов
/ 13 марта 2011

В комментариях есть ссылка на исправление в mySQL 5.0.22 (24 мая 2006 г.) , где это было исправлено.

...