Является ли 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 г.), где это было рассмотрено.