Товарищи, это ж для ][ писалось. Если я не напишу первый обзац таким, чтоб читатель прочитал всю статью - ей грош цена, пусть там хоть крякер инета. И то, что тут рассуждают о содержании, уже говорит о том, что шелкодис в хидере сработал =) Вы достаточно умны, чтобы увидеть несоответствие, и должны понимать его причины. Вступление не соответствует содержанию и сделано это намеренно. Прошу извинить меня за эту уловку и понять её необходимость. А главное, главное то что? Главное, что все описанное в статье - р_а_б_о_т_а_е_т. Демагоги предпочитют доказывать здесь, что "афтар не прав". Но люди, к которым действительно обращена статья, просто молча прочитают и , если будут достаточно упорны, найдут применение материалу. Желаю Вам удачи и терпения. Все получится.
Здесь стоит сказать о недавно найденной уязвимости функций PHP <=5.2.5, <=4.4.8 к мультибайтным символам. Почитать суть баги вы можете здесь: Недостаточная фильтрация GBK в addslashes(). _http://forum.antichat.ru/thread62109.html Практическим применением можно считать уязвимость addslashes() в вордпрессе. WordPress Charset SQL Injection Vulnerability _http://forum.antichat.ru/showpost.php?p=526253&postcount=16 В случае с вордпресом, локаль БД уже должна быть нужной нам. Как правило GBK, как расширенную кодировку, юзают китайцы и японцы(им стандартных 0xFF байт для своего алфавита мало). Однако, атака возможна даже в том случае, если кодировка отлична от уязвимой. Ярким примером может служить недавний эксплоит к SMF 1.1.4 , основанный на изменении кодировки БД. Уязвимость заключается в обходе слеширования addslashes() , используя мультибайтный символ "%a3%27" в кодировке "big5" http://milw0rm.com/exploits/5826 Кстати, спустя несколько месяцев багов по теме подкинул Стефан: http://securityvulns.ru/Tdocument809.html
[offtop] Жаль только что mbstring is a non-default extension, ша даже если надо элементарно mb_detect_encoding() дням со гнем у хостеров не найдешь mbstring. [/offtop]
