Надежна ли функция ADDSLASHES и можно ли ее обойти?

Наверное, ни для кого не секрет, что bUL-инъекции — вещь страшная. Незряони стоят на первом месте в топе OTOWASP'a.
РНР и MySQL — это самая распространенная сейчас связка при разработке web-ресурсов. Важный момент в безопасности — конечно же, фильтрация пользовательского ввода в РНР перед передачей строки запроса в MySQL. По опыту общения с веб-девел опера ми могу сказать, что очень немногие из них разбираются во всевозможных SQL-инъекциях и их подвидах. Чаще всего пользуются какой-нибудь функцией и все. Либо mysql_real_ escape_string (как вариант — без real],либо addslashes. Второй, конечно, реже, но все же пользуются.
Для справки: addslashes добавляет экранирующий символ (то есть слэш «/»] перед символами одинарных (0x27) и двойных (0x22) кавычек, бэкслэшем (0x5с) и перед null-байтом (0x00). Таким образом, данное экранирование лишает взломщика возможности провести инъекцию.
Но в определенных ситуациях мы можем обойти эту функцию. В каких? Когда при взаимодействии с базой данных используются мультибайтовые кодировки — SJIS, BIG5, GBK, СР932. Возможны и другие, но точно не UTF. Могут быть дополнительные ограничения в виде MySQL 4.1.Х-4.1,20, 50.x-50.22 и РНР < 5.2.5 Как видишь, спектр возможных целей сужается, но все же стоит об этом помнить, особенно «работая» с иностранными сайтами.
В чем же суть уязвимости. Для кодировки GBK, например, Oxbf27 — неправильная последовательность, такого символа нет. В то же время символ 0xbf5c — есть. Теперь посмотрим на работу функции addslashes: она берет по одному байту и экранирует его, если необходимо. Oxbf — это «1», 0x27 — это кавычка, ее экранируем.
На выходе получается 0xbf5c27(1\'), но в MySQL воспринимается два символа — Oxbf5с и 0x27, то есть «что-то» и кавычка. SQL-инъекция в простейшем виде будет такой:

http://test.com/Vuln.phpPicb%bf%27 OR 1=1 /*

К описанному выше можно добавить, что и с mysql_escape_string могут быть похожие проблемы, хотя и в очень специфических ситуациях. Подробнее читай в следующих постах:
• shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string;
• ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html;
• kuza55.blogspot.com/2007/06/mysql-injection-encoding-attacks.html;
• raz0r.name/vulnerabilities/sql-inekcii-svyazannye-s-multibajtovymi-kodirovkami-i-addslashes.