ANTICHAT — форум по информационной безопасности, OSINT и технологиям
ANTICHAT — русскоязычное сообщество по безопасности, OSINT и программированию.
Форум ранее работал на доменах antichat.ru, antichat.com и antichat.club,
и теперь снова доступен на новом адресе —
forum.antichat.xyz.
Форум восстановлен и продолжает развитие: доступны архивные темы, добавляются новые обсуждения и материалы.
⚠️ Старые аккаунты восстановить невозможно — необходимо зарегистрироваться заново.
25.05.2009, 09:29
|
|
Познавший АНТИЧАТ
Регистрация: 27.04.2007
Сообщений: 1,044
Провел на форуме:
3660186
Репутация:
905
|
|
Вот хорошая ссылка - https://forum.antichat.ru/search.php
|
|
|
25.05.2009, 09:31
|
|
Познавший АНТИЧАТ
Регистрация: 31.03.2006
Сообщений: 1,167
Провел на форуме:
4072944
Репутация:
1550
|
|
serega393 ну думаю даже если ты ламо то читать все равно умеешь, тема поднималась сотни раз на форуме, а еще человечек Jokester специально для таких как ты создал отдельный топик в уязвимостях
|
|
|
|
25.05.2009, 12:12
|
|
Постоянный
Регистрация: 06.02.2008
Сообщений: 494
Провел на форуме:
1754802
Репутация:
380
|
|
Если какой нибудь способ обойти такую зашиту от sql injection:
if(preg_match('/[^\w-]/',$_POST['id'])) die("wrong <b>id</b>");
далее по коду $_POST['id'] свободно вставляеться в гвери без каких нибудь дополнительных проверок, как я понимаю preg_match бинарнобезопасная функция и ей пофигу на нуль байты и etc.
|
|
|
|
25.05.2009, 14:44
|
|
Members of Antichat - Level 5
Регистрация: 18.02.2008
Сообщений: 1,136
Провел на форуме:
17621293
Репутация:
4915
|
|
Доступны логи, в чём проблема?
http://samovar.teaspoon.ru/?what=../../../../../../../../../../../../proc/self/fd/2%00
|
|
|
|
25.05.2009, 14:58
|
|
Members of Antichat - Level 5
Регистрация: 18.02.2008
Сообщений: 1,136
Провел на форуме:
17621293
Репутация:
4915
|
|
Сообщение от _Quest_
http://samovar.teaspoon.ru/?what=../../../../../../../../../../../../../../../ETC/PASSWD%00
Код:
You will die when I say You must die
WTF?? Мне кажется кто-то спалился. Бага была. теперь её нет
|
|
|
|
25.05.2009, 15:15
|
|
Познающий
Регистрация: 11.09.2008
Сообщений: 99
Провел на форуме:
2753780
Репутация:
585
|
|
PaCo
Ну, можно попробовать придумать сценарий успешного обхода такой проверки. У меня есть некоторые мысли, но чтоб на практике реализовать это, нужно чтоб совпало слишком много всего. Например, в MySQL 4.0.x можно использовать не-ascii-символы в качестве альтернативы пробельным символам в SQL-запросе. PHP же успешно пропустит некоторые такие символы через эту регулярку (не уверен, что всегда, но у меня получалось такое). Т.е. если SQL-инъекция, например, в параметре WHERE опреатора SELECT, и в этом запросе выбирается одна колонка, то запрос:
id=-1ђunionђselectђpasswordђfromђusers
скорее всего обойдет эту регулярку и успешно выполнится. Теоретически (я не пробовал)... (:
Последний раз редактировалось cr0w; 25.05.2009 в 15:23..
|
|
|
|
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..
|
|
|
|
25.05.2009, 17:03
|
|
Познающий
Регистрация: 19.04.2008
Сообщений: 67
Провел на форуме:
596695
Репутация:
19
|
|
странная SQL inj
При запросе www.host.ru/new/?' вылазит ошибка
Код:
insert into statistic(resource,charset,user_agent,remote_addr,method,URI,DC) values (' - equipment','windows-1251','Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)','IP','GET','/new/?'',NOW())<br>: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''/new/?'',NOW())' at line 1
В дальнейшем на
+order+by+10000--
+order+by+10000/*
'+order+by+10000--
?-1+order+by+10000--
просто выводит страницу...+ на /**/ заменял....как обойти такую фильтрацию, или может нужно по другому запрос сделать?
ПС. Все хедеры отправляю HttpREQ, т. к. браузер даже на /new/?' не реагирует. |
|
|
|
25.05.2009, 17:10
|
|
Постоянный
Регистрация: 06.02.2008
Сообщений: 494
Провел на форуме:
1754802
Репутация:
380
|
|
Ты на запрос посмотри - там тока блаинд.
|
|
|
|
25.05.2009, 17:18
|
|
Познающий
Регистрация: 19.04.2008
Сообщений: 67
Провел на форуме:
596695
Репутация:
19
|
|
Я понимаю что блинд. но запросы то +order+by+1000000-- и +order+by+1-- должны возвращать разные результаты...или нужно использовать подзапросы?
|
|
|
|
|
|
Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
|
|
|
|
Линейный вид
