Отличная статья! Даю оценку 9 из 10. Один балл снят за некоторые опечатки и недосмотры (мелкие!), что, в прочем, сути не меняет. Все предельно ясно изложено!
Всё, правильно, только можно несколько проще поступать, есть ещё например справочники логинов, да и логины к базам для использования из пхп, как правило не от балды дают... Есть ещё одна вещь: если есть такой опасный скрипт, то можно и не подбирать логин, особенно если версия mysql <4.0, для этого уже где то был експлойт достающий хешь и логин пользователя от которого запущен скрипт (использует багу в самом mysql)...
В целом полезно, с точки зрения того, что писать надо гораздо аккуратнее, но в действительности всё даже несколько хуже...
неплохо, правда баггзи об этом уже писал... Кстати, а почему регистро-независимая проверка? Если пароль ТаКоЙ, то потом всеравно прийдется дополнительно проверять регистры... Хотя это и не играет никакой роли...
Отличная статья! Но, хотя в тематику таких статей и не входит описание гарантированной защиты от SQL Injection (поскольку подразумевается, что она читателю известна), всё-же, учитывая широту аудитории, было бы неплохо, на мой взгляд, защиту описать. Для PHP довольно простым языком методика составления запросов описана в PHP FAQ: Cоставление запросов mysql. Но, конечно же, эта схема подходит и для любых других языков.
Чебурген пишет: Отличная статья! Но, хотя в тематику таких статей и не входит описание гарантированной защиты от SQL Injection (поскольку подразумевается, что она читателю известна), всё-же, учитывая широту аудитории, было бы неплохо, на мой взгляд, защиту описать. Для PHP довольно простым языком методика составления запросов описана в PHP FAQ: Cоставление запросов mysql. Но, конечно же, эта схема подходит и для любых других языков.
В этом документе описано только экранирование кавычек, что все-же не будет полной защитой. Желательно любые данные перед вставкой в запрос дополнительно прогонять через регулярное выражение.
1dt.w0lf пишет: В этом документе описано только экранирование кавычек, что все-же не будет полной защитой.
Это неправильное мнение. Те два правила, которые там описаны, при строгом выполнении гарантируют полную защиту. И все эксплойты основаны именно на несоблюдении правил составления запросов.
Цитата
1dt.w0lf пишет: Желательно любые данные перед вставкой в запрос дополнительно прогонять через регулярное выражение.
Регулярное выражение - это слишком общий термин. Что именно должно делать это регулярное выражение, и зачем? Хотелось бы увидеть, так же, пример данных, которым недостаточно прослешивания, а нужен прогон через регулярное выражение.
Цитата
1dt.w0lf пишет: Обходится с помощью использования списка прокси.
А я и не писал, что это панацея. Однако, помочь, все же, может. К тому же, достаточно большой для посимвольного перебора список гарантированно рабочих проксей... Это тоже не фунт изюму. Впрочем, эта тема будет совсем уже оффтопик, и развивать я ее не буду. Лучше заранее соглашусь, что, в отличие от механизма правильного составления запросов, антифлудеры 100% гарантии, конечно же, не дают.
Хотелось бы увидеть, так же, пример данных, которым недостаточно прослешивания, а нужен прогон через регулярное выражение.
Первый пример из статьи. Там одного прослешивания недостаточно так как кавычки не используются в запросе.
Цитата
Чебурген пишет:
А я и не писал, что это панацея. Однако, помочь, все же, может. К тому же, достаточно большой для посимвольного перебора список гарантированно рабочих проксей...
Величина списка проксей зависит от длины строки которую требуется перебором получить. Иногда и 500 проксей хватит за глаза а это не такой уж и большой список.
Понятно. Вы просто невнимательно прочли ссылку, что я дал. Там описано не только экранирование кавычек.
Цитата
прослешивания недостаточно так как кавычки не используются в запросе.
Ну вот с этого и надо было начинать. Кавычки не используются в запросе. Все правильно. Но какое это имеет отношение к тексту по ссылке, которую я привел? Позволю себе процитировать:
Цитата
Два основных правила составления запросов в 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: сама по себе, директива неправильная, и опытный девелопер ее отключит. Но она везде по умолчанию вкючена. Да, криво. зато немного надежнее для чайников.
Не совсем понятно: в начале статьи сказано, что она в частности решает следующую проблему: "атакующий не располагает никакой информацией о структуре базы." однако никаких методов для узнавания названий таблиц и столбцов в статье не предложено. Даже напротив, мы видим такие строки: "Предположим, что в некоторой базе данных существует таблица users в которой хранится информация о существующих пользователях как то логин пользователя (столбец login), пароль пользователя (столбец password) и информация о регистрации пользователя (столбец status...)" и нигде ни разу не рассказывается, как узнать названия столбцов, таблиц и вообще их количество..