Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Регистрация
Войти
 
Страницы: 1 2 След.
RSS
Посимвольный перебор в базах данных на примере MySQL
 
Обсуждение статьи Посимвольный перебор в базах данных на примере MySQL
 
вульф,молодца. #rst болеет за тебя ;)
____________________________________
з.ы. желаем чтобы нотик был твоим.
подпись - сам знаешь кто:)
 
Отличная статья!
Даю оценку 9 из 10.
Один балл снят за некоторые опечатки и недосмотры (мелкие!), что, в прочем, сути не меняет. Все предельно ясно изложено! ;-)
 
Всё, правильно, только можно несколько проще поступать, есть ещё например справочники логинов, да и логины к базам для использования из пхп, как правило не от балды дают...
Есть ещё одна вещь:
если есть такой опасный скрипт, то можно и не подбирать логин, особенно если версия mysql <4.0, для этого уже где то был експлойт достающий хешь и логин пользователя от которого запущен скрипт (использует багу в самом mysql)...

В целом полезно, с точки зрения того, что писать надо гораздо аккуратнее, но в действительности всё даже несколько хуже...:(
 
неплохо, правда баггзи об этом уже писал...
Кстати, а почему регистро-независимая проверка? Если пароль ТаКоЙ, то потом всеравно прийдется дополнительно проверять регистры... Хотя это и не играет никакой роли...
 
Отличная статья!
Но, хотя в тематику таких статей и не входит описание гарантированной защиты от SQL Injection (поскольку подразумевается, что она читателю известна), всё-же, учитывая широту аудитории, было бы неплохо, на мой взгляд, защиту описать. Для PHP довольно простым языком методика составления запросов описана в
PHP FAQ: Cоставление запросов mysql.
Но, конечно же, эта схема подходит и для любых других языков.

А от посимвольного перебора помогают различные антифлудеры, например, http://php.spb.ru/other/_dima_noflood.php от Дмитрия Бородина.
 
Цитата
Чебурген пишет:
Отличная статья!
Но, хотя в тематику таких статей и не входит описание гарантированной защиты от SQL Injection (поскольку подразумевается, что она читателю известна), всё-же, учитывая широту аудитории, было бы неплохо, на мой взгляд, защиту описать. Для PHP довольно простым языком методика составления запросов описана в
PHP FAQ: Cоставление запросов mysql.
Но, конечно же, эта схема подходит и для любых других языков.

В этом документе описано только экранирование кавычек, что все-же не будет полной защитой. Желательно любые данные перед вставкой в запрос дополнительно прогонять через регулярное выражение.

Цитата
Чебурген пишет:

А от посимвольного перебора помогают различные антифлудеры, например, http://php.spb.ru/other/_dima_noflood.php от Дмитрия Бородина.

Обходится с помощью использования списка прокси.
 
Цитата
1dt.w0lf пишет:
В этом документе описано только экранирование кавычек, что все-же не будет полной защитой.
Это неправильное мнение.
Те два правила, которые там описаны, при строгом выполнении гарантируют полную защиту.
И все эксплойты основаны именно на несоблюдении правил составления запросов.
Цитата
1dt.w0lf пишет:
Желательно любые данные перед вставкой в запрос дополнительно прогонять через регулярное выражение.
Регулярное выражение - это слишком общий термин. Что именно должно делать это регулярное выражение, и зачем?
Хотелось бы увидеть, так же, пример данных, которым недостаточно прослешивания, а нужен прогон через регулярное выражение.
Цитата
1dt.w0lf пишет:
Обходится с помощью использования списка прокси.
А я и не писал, что это панацея. Однако, помочь, все же, может.
К тому же, достаточно большой для посимвольного перебора список гарантированно рабочих проксей... Это тоже не фунт изюму. Впрочем, эта тема будет совсем уже оффтопик, и развивать я ее не буду. Лучше заранее соглашусь, что, в отличие от механизма правильного составления запросов, антифлудеры 100% гарантии, конечно же, не дают.
 
Цитата
Чебурген пишет:

Хотелось бы увидеть, так же, пример данных, которым недостаточно прослешивания, а нужен прогон через регулярное выражение.

Первый пример из статьи. Там одного прослешивания недостаточно так как кавычки не используются в запросе.

Цитата
Чебурген пишет:

А я и не писал, что это панацея. Однако, помочь, все же, может.
К тому же, достаточно большой для посимвольного перебора список гарантированно рабочих проксей...

Величина списка проксей зависит от длины строки которую требуется перебором получить. Иногда и 500 проксей хватит за глаза а это не такой уж и большой список.

Цитата
Чебурген пишет:

Это тоже не фунт изюму.

Согласен.
 
А не надоело писать про SQL-injection? Тем более что автор ничего нового не рассказал - просто очередная статья на старую тему.
Например, об этом говорили на BlackHat'е:
"Blind SQL Injection Automation Techniques"
http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-hot chkies/bh-us-04-hotchkies.pdf
Архив с дополнительными статьями и PoC'ами:
http://www.blackhat.com/presentations/bh-usa-04/bh-us-04-hot chkies/bh-us-04-hotchkies-tools-refs.zip

И вообще что за тенденция брать чужие наработки и переписывать и при этом ничего нового не добавлять?

Печально, что в последнее время поубавилось людей способных “изобретать” что-то оригинальное...
 
Понятно. Вы просто невнимательно прочли ссылку, что я дал. Там описано не только экранирование кавычек.
Цитата
прослешивания недостаточно так как кавычки не используются в запросе.
Ну вот с этого и надо было начинать. Кавычки не используются в запросе. Все правильно. Но какое это имеет отношение к тексту по ссылке, которую я привел?
Позволю себе процитировать:
Цитата
Два основных правила составления запросов в mysql:
- все вставляемые в запрос данные должны быть заключены в кавычки(одинарные или двойные, но удобнее и чаще используются одинарные).
- во всех переменных должны быть экранированы слешами спецсимволы.
Я специально выделил жирным шрифтом. Теперь лучше видно?
Там ещё, ниже, примеры есть.
И, ещё ниже, написано, что "для надежности лучше заключать в кавычки данные любых типов".
Именно этой рекомендации не последовал автор запроса из первого примера в статье.
Да, он мог проверить тип $id регулярным выражением. Мог проверить по-другому. Но он этого не сделал.
В любом случае, его проблемы никак не опровергают того факта, что если следовать ОБОИМ правилам составления запросов, то взлом будет невозможен.
 
Цитата
Чебурген пишет:

Позволю себе процитировать:
Цитата
Два основных правила составления запросов в mysql:
- все вставляемые в запрос данные должны быть заключены в кавычки(одинарные или двойные, но удобнее и чаще используются одинарные).
- во всех переменных должны быть экранированы слешами спецсимволы.
Я специально выделил жирным шрифтом. Теперь лучше видно?
Там ещё, ниже, примеры есть.
И, ещё ниже, написано, что "для надежности лучше заключать в кавычки данные любых типов".
Именно этой рекомендации не последовал автор запроса из первого примера в статье.
Да, он мог проверить тип $id регулярным выражением. Мог проверить по-другому. Но он этого не сделал.

В данном примере полностью с Вами согласен.

Цитата
Чебурген пишет:

В любом случае, его проблемы никак не опровергают того факта, что если следовать ОБОИМ правилам составления запросов, то взлом будет невозможен.

А вот тут вынужден несогласиться так как вы забываете, что все зависит еще и от вида запроса. Т.е. например такой запрос: select ... limit $var , в данном запросе вы же не сможете взять переменную в кавычки.
Или если кодер позволит менять названия столбцев для выбора select $a , $b , $c from ... тут кавычки тоже отпадают.
 
А действительно.
Мда, спасибо... Это очень ценное замечание.
 
фак! что делать
выдаёт бадягу
[Can't locate object method "post" via package "LWP::UserAgent" (perhaps you for
got to load "LWP::UserAgent"?) at C:\1\123.pl line 105.

попытался обновить компонент через PPM но не помогло...
 
Цитата
Чебурген пишет:
Понятно. Вы просто невнимательно прочли ссылку, что я дал. Там описано не только экранирование кавычек.
Цитата
прослешивания недостаточно так как кавычки не используются в запросе.
Ну вот с этого и надо было начинать. Кавычки не используются в запросе. Все правильно. Но какое это имеет отношение к тексту по ссылке, которую я привел?
Позволю себе процитировать:
Цитата
Два основных правила составления запросов в mysql:
- все вставляемые в запрос данные должны быть заключены в кавычки(одинарные или двойные, но удобнее и чаще используются одинарные).
- во всех переменных должны быть экранированы слешами спецсимволы.
Я специально выделил жирным шрифтом. Теперь лучше видно?
Там ещё, ниже, примеры есть.
И, ещё ниже, написано, что "для надежности лучше заключать в кавычки данные любых типов".
Именно этой рекомендации не последовал автор запроса из первого примера в статье.
Да, он мог проверить тип $id регулярным выражением. Мог проверить по-другому. Но он этого не сделал.
В любом случае, его проблемы никак не опровергают того факта, что если следовать ОБОИМ правилам составления запросов, то взлом будет невозможен.

Как я думаю везде ставить кавычки только из-за того чтобы не было sql-inj, не разумно(в некоторых случаях не возможно). Как-то криво получается. Вот как я решаю эту проблему( и не только я :)).
для integer:
mysql_query('SELECT login FROM users WHERE id ='. (int)$id);
для string:
mysql_query("SELECT passwd FROM users WHERE login = '".addslashes($login)."'");

А статья очень интересная.
 
Ничуть не криво. А часто оказывается даже удобнее.
Очень облегчает, к примеру, автоматическое составление запросов insert и update.
Однако, никто, конечно же, не заставляет пользоваться только кавычками.
Речь не идет о том, что надо обязательно пользоваться только ими. А о том, что этот способ гарантирует защиту.
Это то же самое, что и magic_qootes: сама по себе, директива неправильная, и опытный девелопер ее отключит.
Но она везде по умолчанию вкючена. Да, криво. зато немного надежнее для чайников.
 
Мне статья понравилась
 
некотрые моменты, описанные в статье, почти дословно коррелируют вот с этим
http://www.spidynamics.com/whitepapers/Blind_SQLInjection.pd f
Хотя эта статья и посвящена другому типу базы данных, все равно очень похоже.
 
Статья очень рулезная!
Щас активно пользуюсь данными методами, написал для этого свой более совершенный крякер [IMG]http://www.securitylab.ru/forum/smileys/smiley36.gif[/IMG]
 
Не совсем понятно:
в начале статьи сказано, что она в частности решает следующую проблему: "атакующий не располагает никакой информацией о структуре базы."
однако никаких методов для узнавания названий таблиц и столбцов в статье не предложено. Даже напротив, мы видим такие строки: "Предположим, что в некоторой базе данных существует таблица users в которой хранится информация о существующих пользователях как то логин пользователя (столбец login), пароль пользователя (столбец password) и информация о регистрации пользователя (столбец status...)"
и нигде ни разу не рассказывается, как узнать названия столбцов, таблиц и вообще их количество..
Страницы: 1 2 След.
Читают тему (гостей: 1)