25.05.2009, 15:53
|
|
Постоянный
Регистрация: 06.02.2008
Сообщений: 494
Провел на форуме:
1754802
Репутация:
380
|
|
Сообщение от cr0w
PaCo
Ну, можно попробовать придумать сценарий успешного обхода такой проверки. У меня есть некоторые мысли, но чтоб на практике реализовать это, нужно чтоб совпало слишком много всего. Например, в MySQL 4.0.x можно использовать не-ascii-символы в качестве альтернативы пробельным символам в SQL-запросе. PHP же успешно пропустит некоторые такие символы через эту регулярку (не уверен, что всегда, но у меня получалось такое). Т.е. если SQL-инъекция, например, в параметре WHERE опреатора SELECT, и в этом запросе выбирается одна колонка, то запрос:
id=-1ђunionђselectђpasswordђfromђusers
скорее всего обойдет эту регулярку и успешно выполнится. Теоретически (я не пробовал)... (:
в том то и вся лажа(я забыл упомянуть) что в запрос идет $_POST['id'] в двойных кавычках, фактически мне достаточно и того что бы просто нарушить как то запрос,вызвать ошибку(есть другая скуля но для ее экплотации необходим префикс и в ней еррор не выводится вообше) а в этой скули в случаи неудачи выводится весь запрос с префиксом,а про то что \w может пропустить не совсем печатные символы которые некоторые версии мускуля могут воспринять как пробел( в зависимости от того как был собран PCRE) я в курсе, но двойную ковычку там ничего не заменит, в попытках вызвать Illegal mix of collations я уже испробывал все возможные кодировки, вот запрос которые идет в базу:
PHP код:
SELECT content_name FROM $base.".$prefix_."content_item WHERE $base.".$prefix_."content_item.content_name = \"" . $_POST['id'] . "\" LIMIT 1";
content_name:
varchar(100) ,utf8_unicode_ci, по умолчанию null
Последний раз редактировалось PaCo; 25.05.2009 в 15:57..
|
|
|