Является ли mysql_real_escape_string() сломанным?
Некоторые люди считают, что mysql_real_escape_string() имеет некоторые недостатки и не может защитить ваш запрос даже при правильном использовании.
В качестве доказательства можно привести некоторые ископаемые статьи.
Итак, возникает вопрос: mysql [i] _real escape_string() абсолютно неприемлемо?
Или можно ли использовать эту функцию для создания ваших собственных подготовленных заявлений?
С кодом проверки, пожалуйста.
Ответы
Ответ 1
Из Функция API MySQL MySQL 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, но PHPs mysql_set_charset, чтобы изменить кодировку, поскольку это является эквивалентом MySQLs mysql_set_character_set (см. исходный код/ext/mysql/php_mysql.c).
Ответ 2
Однако даже с устаревшим кодом и старыми версиями сервера эта уязвимость может быть запущена только в том случае, если набор символов соединения с базой данных изменяется от однобайтового, такого как Latin-1, до многобайтового, что позволяет использовать значение 0x5c ( ASCII) во втором или более позднем байте многобайтового символа.
В частности, UTF-8 не позволяет этого, в отличие от старых азиатских кодировок, таких как GBK и SJIS. Поэтому, если ваше приложение не изменит набор символов соединения или изменит его только на UTF-8 или однобайтовые, такие как Latin-n, вы можете быть в безопасности от этого эксплойта.
Но лучше всего использовать новейшую версию сервера, использовать правильный интерфейс для изменения наборов символов и использовать подготовленные запросы, чтобы вы не забывали избегать вещей.
Ответ 3
В комментариях есть ссылка на исправление в mySQL 5.0.22 (24 мая 2006 г.), где это было рассмотрено.
