Проведение sql-injection на ms sql и mysql серверах
Уязвимости класса sql-injection являются одной из самых актуальных проблем сетевой безопасности, т.к. с помощью подобной атаки проводимой хакером возможно получение паролей пользователей находящихся в базе данных sql сервера. По моим последним наблюдениям до 80% веб ресурсов сети подвержены подобным атакам, это относится и к крупным проектам. Как же защить свой скрипт? Ответ прост - фильтровать данные полученые от пользователя, но к сожалению (а для хакера к счастью) во множестве публичных скриптах, что особенно опасно, этого не наблюдается. Так же проведению атаки взломщику поможет и неправильная настройка сервера, поэтому всегда нужно точно следовать руководству самого производителя ПО. Перед составлением скрипта разработайте собственную архитектуру, например фильтруйте данные перед тем как они понадобятся. Не используйте опасных функций в которые даже после фильтровки идут пользовательские данные к примеру php функция eval в большенстве случаев заменима, но вред который она может принести значителен как и любая php-injection. На этом краткий ввод в безопасность я считаю оконченным, могу лишь добавить что взлом это 99% человеческий фактор - ПО делают люди. Что бы сделать скрипт безопасным проверяйте его всегда сами, чтобы защить сайт от хакера нужно думать как хакер. Теперь попробуем взломать сами себя, чтобы в последствии защить свой сайт и т.д. от хакера.
Ошибки связанные с sql-injection
Здесь я опущу описание взлома через очевидные ошибки возвращаемые сервером. Пусть после подставления ' мы не получили ни одного сообщения об ошибке, сразу скажу что это не значит что ошибок нет - это значит что либо таковы настройки сервера, либо в самом скрипте идет внутрення обработка ошибок уже ПОСЛЕ запроса к sql серверу. Пусть запрос к веб ресурсу xaxa.com выглядит следующим образом
http://xaxa.com/index.php?id=5 и при подставновке кавычки в id сервер не сообщает об ошибке sql запроса. Для начала нужно выяснить какой тип действительно передается в базу данных, id=5 не значит что запрос идет с типом int вполне возможно что это строка. Сделаем следующие отправим скрипту id=6 и если возвращается страница отличная от индекса (скорее всего скрипт напишет не найдена страница) то отправим id=6%2d1 и если возвратится тот же самый результат что и при запросе id=5 то уязвимость скорее всего есть. Если нет тогда предположим что передается строка при id=5 так:
select page_title,page_text from pages where page_id='5'
тогда согласитесь что вполне корректным запросом будет select page_title,page_text from pages where page_id='5'+'1', даже если бы там стояли скобки. Из предположения о работе скрипта отправим в качестве id значение равное 5'%2b'1 если возвратится результат такой же что и при запросе id=51 или вылезет много страниц можно считать что уязвимость есть. Теперь попробуем сделать саму инъекцию. Пусть запрос выглядит так:
Код:
select page_title,page_text from pages where (page_id='5')and(page_status>0)
тогда нам нужно подставить такое page_id что бы получился коректный запрос к базе. Попробуем отправить id=5')-- если результатом будет ошибка то возможно запрос подается нев одной строке попробуйте так id=5')/* . Преположим мы добились положительного ответа от сервера, тогда как нам использовать полученый результат? В большенстве случаев потребуется определение версии sql сервера. Наиболее распространнем сейчас является MySQL новых версий в которых добавлено использование оператора UNION. Сделаем следующий запрос:
Код:
select page_title,page_text from pages where (page_id='5')union select null,null/*')and(page_status>0)
этот запрос будет коректен будет возвращен тот же самый запрос что и при запросе с id=5. Теперь подобрав количество столбцов для объеденения подстваим
Код:
id=5')union select 10000%2b1,20000%2b1/*
теперь в исходном коде получившейся страницы попробуем найти строки типа 10001 или 20001 если такие были найдены то это очень облегчит нашу задачу. Теперь пусть на сервере есть таблица пользователями находящияся и в той же базе что и pages. Составим запрос с
Код:
id=5')union select user_name,20000%2b1 from users/*
и если в месте где было 10001 мы увидим строчку с именем пользователя то можно считать инъекцию успешной. Если это не так тогда имя поля с именами пользователей таблицы users подобранно неправильно. Возможн вариант что при ВЫХОДЕ данные фильтруются для проверки такого предположения составим запрос с
Код:
id=5')union select 0x5841,20000%2b1/*
и если в исходном коде страницы будет видно надпись XAXA то никакие проверки на выходе не идут и все хорошо. В противном случае придется использовать "логику запросов". Например в простейшем случае, если выводится число 10001 то сделаем запрос с
Код:
id=5')union select ascii(lawer(substring(user_name,1,1))),20000%2b1 where user_id=1/*
если в полученом коде возвращаемой страницы на месте 10001 бедт стоять число отличное от нуля то инъекция опять таки проведена успешно, таким образом за несколько подобных запросов можно перебрать и пароль и имя любого пользователя. Возможно вариант что числа 10001 не видно в сурсе, что делать тогда? Наилучшем вариантом будет поддержка подзапросов, например
Код:
select page_title,page_text from pages where (page_id='5')and((select ascii(lawer(substring(user_name,1,1))) from users where user_id=1)>100)/*')and(page_status>0)
тогда скрипт выведет что либо только если результат второй скобки обращается в true или первый символ первого пользователя имеет ASCII код больший 100. Таким образом за некоторое количество запросов подобрать имя и пароль пользователя всегда возможно. А что делать если подзапросы данный сервер не поддерживает? Тогда попробуем сосздать следующей запрос к базе данных:
Код:
select page_title,page_text from pages where (page_id='-555')union select pages.page_title,pages.page_text from pages,users where pages.page_id='5' and(ascii(lawer(substring(users.user_name)))>100)and(users.user_id=1)/*')and(page_status>0)
Понятно что первый selec не возвратит в результате null, а второй как раз в качестве двух столбцов возратит тоже что и при id=5 но при дополнительном условии - если первый символ имени пользователя с user_id=1 имеет ASCII код больший 100. Таким образом после такого перебора в конце концов взломщик сможет получить незащищенные данные пользователей вплоть до паролей. Еще одна "хитрость" sql (работает как и в mysq, так и в mssql) пусть нам нужно возвратить для анализа скрипта строку XAXA тогда нам понадобятся кавычки которые могут фильтроваться. Выхода из такой ситуации два функция char, которая в mssql отказывается нормально работать, и использование 16-ти битной кодировки, которую sql понимает как строчку. Второй вариант мне больше подуше и поэтому вот php скрипт возвращающий 16 битное значение строчки:
Код:
<?
echo('0x'.bin2hex($str));
?>
Таким образом вместо 'XAXA' вполне допустимо подставлять 0x58415841. Если же на сервере запущен mssql, то в проведении инъекции обычно не возникает сложностей благодаря возможностям своего синтаксиса, сюда можно отнести и выполнение команд на сервере и реализация подзапросов.
Заключение
Здесь была описана методика внедрения sql кода в запрос скрипта больше описывать бессмысленно т.к. для этго существуют справочники и документации на официальных сайтах mysq, msssql, oracle и т.д. Все сотальные навыки по защите/взломе накапливаются только с опытом и собственными исследованиями.
Статья написана
ZaCo специально для kot777,
m0nzt3r и раздела Безопасность WEB - приложений.
Продолжение следует...
SQL инъекция (в т.ч. и blind SQL)
Похожие темы
Древовидный вид