SQL-Инъекции
Здравствуйте. Мы приступаем к изучению одной из самых распространенных веб-атак - SQL-инъекции.
В данной статье будут дано достаточно материала, чтобы вы смогли уловить общую концепцию и продолжить изучение самостоятельно.
Но прежде чем приступить к делу, я хотел бы акцентировать ваше внимание на одном важном моменте:
Это будет для вас полезнее в десятки раз, чем все сотню раз переписанные статьи со школо-хэко-форумов где учат копипастить URLы в Havij. Я думаю будет уместно дополнить, что чтение более серьезных книг по SQL и технической документации по конкретным СУБД будет еще полезнее, чем "10 минут на урок".
Ну а теперь, когда меньшиство посетителей уже закрыло вкладку (большинство и не открывало), мы с вами перейдем к делу.
Что такое SQL-инъекция?
Существует два вида приложений. Первый вид - приложение, которое ведет себя именно так, как задумал программист. Второй - приложение, которое ведет себя не совсем так, как задумал программист.
И вся суть SQL-инъекции (а также php-инъекций, xml-инъекций и т.д.) состоит в том, чтобы найти приложение второго вида и заставить его выполнить некоторое полезное нам действие, возможность которого не планировалась программистом.
К примеру, есть некий скрипт articles.php. И туда методом Get передается значение параметра id.
Кодер когда писал свое приложение думал примерно так:
В зависимости от того, что мы будем передавать в параметр id, приложение будет возвращать разный результат.
Но любой результат можно свести к одному из трех вариантов:
Очевидно, что в суровой действительности веб-приложение ведет себя не совсем так, как это представлялось кодеру в его влажных мечтах. И по сути, в последнем варианте параметр/значение мы уже провели небольшую SQL-инъекцию.
Остается дело за малым - раскрутить эту самую инъекцию (попробовать вывести данные из бд, прочитать файлы, залить шелл и т.д.)
Стоит сразу отметить 2 нюанса:
Виды SQL-инъекций
SQL-инъекции разделяют на множество видов
1) По типу переменной:
Integer (целочисленная). Параметр не обрамлен кавычками:
String (строковая). Параметр обрамлен кавычками:
2) По типу SQL-запроса и месту инъекции в запросе. В теории, инъекция может быть в абсолютно любом месте абсолютно любого SQL-запроса, если туда попадают недостаточно фильтруемые данные. Чаще всего инъекции находят в SELECT (отдельно выделяют инъекции после order by, потому как их реализация чуть сложнее), реже в UPDATE, INSERT, DELETE. Поэтому можно встретить разделение - Update based, Insert based и т.д.
3) Данные в SQL-запрос могут попадать через Get, Post, Cookie, HTTP заголовки (реферрер, юзерагент, или еще что-то, на что хватит фантазии у программиста).
Также стоит отметить такой класс инъекций как Second order injection. Это когда данные попадают в SQL-запрос не напрямую от пользователя (get, post, cookie, http headers), а из БД, из файла, от самого Аллаха или еще из какого места куда мы могли ранее ввести данные.
К примеру, есть форма регистрации (все очень условно):
Данные экранируются, SQL-инъекции нет. Далее, форма авторизации:
И наконец форма для смены пароля:
Тут тоже нет SQL-инъекции. Но! Если зарегистрировать пользователя с логином "admin' #", то можно сменить пароль для пользователя "admin", не зная его действующий пароль (проверьте на досуге). Это и будет Second order SQL-injection.
4) По типу SQL-инъекции:
4.1) Union-based. Инъекция в SELECT запросе, вывод данных из БД производится с помощью оператора UNION. Этот метод работает, когда веб-приложение напрямую возвращает результат вывода команды SELECT на страницу (поэтому без разницы, включен вывод ошибок или нет).
В начале стоит 9999.9 (хотя могло быть и 0, -1 и т.д.) для того, чтобы первый запрос вернул пустой результат, а второй (уже внедренный нами), вернул то, что нам нужно.
4.2) Error-based (double query). Если использовать UNION не получается (нет колонки для вывода или инъекция в UPDATE, INSERT или DELETE), то можно вывести данные из базы искусственно вызывая ошибки.
Например такой запрос:
Вызовет ошибку, в отчете о которой мы увидим данные, которые нам были нужны:
4.3) Blind-based (boolean based). Если данные нельзя вывести через union, а ошибки никак не выводятся, то скорее всего мы имеем дело со слепой инъекцией.
Как вы помните, приложение может вернуть либо нормальный результат, либо пустой, либо ошибку. Ошибки в данном случае подавляются. Поэтому мы можем использовать только, что пустой ответ это false, а нормальный ответ - true.
И это только чтобы узнать, что первый символ в имени пользователя базы данных это "r" (114 это ascii-код этого символа).
4.4) Time-based (double blind). А теперь представьте, что SQL-инъекция есть, но результат отдаваемый веб-приложением, не меняется вообще никак. Нельзя как-то выделить, что будет false, а что будет true? Что делать тогда? Использовать временные задержки.
Там где будет True, сервак будет тупить 10 секунд, прежде чем вернуть страницу. В остальном все идентично обычным слепым (boolean based) инъекциям.
Чтобы как-то уложилось в голове (вывод ошибок - от СУБД!):
Теперь, по мере изучения дальнейших материалов, вы, надеюсь, не будете путаться в классификации инъекций. Если что-то было непонятно, вы с легкостью восполните пробелы в знаниях, изучив соответствующие материалы.
Материалы:
SQL
Манипуляции с базой данных. В базе данных может быть что угодно.
Если у нас есть возможность читать данные из бд, мы можем узнать много интересного:
Запись в файл/чтение файлов. Если звезды сложились удачно и у нас есть достаточно прав, известен абсолютный путь к файлам и не фильтруются кавычки, мы можем с легкостью залить шелл. Читать файлы можно даже при ограниченных правах. Например, можно прочесть из конфига логин/пароль от соединения с базой данных, и если повезет, подключиться напрямую. Если очень повезет - узнать пароль от фтп (в конфигах jooml'ы иногда хранится).
SiXSS. Union based и Error based инъекции позволяют провести XSS атаку.
этого, вместо вывода данных из таблицы, мы пишем необходимый нам js-код:
По сути - это тоже самое, что и пассивная XSS (она же отраженная), т.к. вся нагрузка уже в самом запросе.
Но в отличии от обычной пассивки, она способна обойти защиту большинства браузеров (которые хавают обычные пассивки на раз-два):
Обход авторизации. Если уязвимость спряталась в форме авторизации, то вам не нужно будет знать пароль (а иногда и логин) для входа под учеткой другого пользователя/администратора.
SQLi + Denial of Service. С помощью одного нехитрого запроса можно повалить сайт к ебени-матери (например используя вложенный Benchmark).
Практика.
Чтобы действительно вьехать в тему, недостаточно просто изучить теорию.
Нужно обязательно практиковаться:
Автоматизация.
Частенько мелькают сообщения на андергрант-форумах, дескать илита не пользуется софтом, а раскручивает все ручками. Возможно где-то и есть уникумы, которые time based скулю раскручивает с секундомером в руках, в качестве браузера используют telnet на 80 порт, а md5 хеши брутфорсят с помощью калькулятора, карандаша и листа A4, но мы к такой илите не относимся (мы вообще к илите не относимся).
Как я уже советовал вам ранее, поставьте Burp Suite. Хотя вы можете использовать любые другие отладочные прокси (Fiddler, Charles и т.д.), это уже скорее дело привычки, но Burp Suite все-таки заточен именно под поиск и эксплуатацию уязвимостей. Берем http-запрос, отправляем в Intruder, сразу смотрим результат. Шик же.
Если говорить об автоматизации sql-инъекций, то тут две софтины впереди планеты всей.
havij - утилита must have для школо-хеккера (а также сценарной детки). Многие из тех кто используют эту программу, не знают, как провести атаку, если уязвимый параметр передается Post'ом или в куках. И это при том, что есть вполне сносная справка на сайте.
Любознательным товарищам будет полезно запустить havij через прокси (тот же burp suite или fiddler), чтобы увидеть и понять, как именно работает havij. Софт заточен под винду, имеет free и pro версию. "Крякнутые" версии практически всегда с чем-то склеены, и не обладают полным функционалом.
Определенно, есть много объективных причин (и все на поверхности), почему софт так популярен в массах. Есть масса аналогов, Pangolin, SQLi-helper и других, которые даже до havij не всегда дотягивают. Те же яйца, вид сбоку.
sqlmap - на сегодняшний день, это лучший софт, для автоматизации SQL-инъекций. Любой пацык на районе подтвердит. Правда, нужно установить питон. И программа консольная (хотя и GUI обертку легко найти). Но это тока шобы отпугивать всякую шерсть, которая не сечет фишку.
Чтобы подтянуть знания по SQL-инъекциям, можно посмотреть исходники sqlmap (ну или поснифать запросы через веб-прокси).
Алгоритм для автоматизации простой:
Можно поставить плагин для burp (https://code.google.com/p/gason/) и отправлять запрос из Burp Proxy в sqlmap двумя кликами.
Это что касается автоматизации тестирования на sql-инъекции на одном сайте. Если вам нужно чекнуть на скули несколько десятков (сотен, тысяч) сайтов, то алгоритм, приведенный выше, вряд ли подойдет (если только вы не Дункан Маклауд).
Веб хакинг [часть 1]
Веб хакинг [часть 2]
Веб хакинг [...]
Здравствуйте. Мы приступаем к изучению одной из самых распространенных веб-атак - SQL-инъекции.
- Введение.
- Что такое SQL-инъекция?
- Виды SQL-инъекций.
- Материалы по уязвимостям.
- Как можно использовать SQL-инъекции?
- Практика.
- Автоматизация.
В данной статье будут дано достаточно материала, чтобы вы смогли уловить общую концепцию и продолжить изучение самостоятельно.
Но прежде чем приступить к делу, я хотел бы акцентировать ваше внимание на одном важном моменте:
- Если вы до сих пор не разобрались с языком SQL, то дальнейшее чтение для вас бессмысленно.
Это будет для вас полезнее в десятки раз, чем все сотню раз переписанные статьи со школо-хэко-форумов где учат копипастить URLы в Havij. Я думаю будет уместно дополнить, что чтение более серьезных книг по SQL и технической документации по конкретным СУБД будет еще полезнее, чем "10 минут на урок".
Ну а теперь, когда меньшиство посетителей уже закрыло вкладку (большинство и не открывало), мы с вами перейдем к делу.
Что такое SQL-инъекция?
Существует два вида приложений. Первый вид - приложение, которое ведет себя именно так, как задумал программист. Второй - приложение, которое ведет себя не совсем так, как задумал программист.
И вся суть SQL-инъекции (а также php-инъекций, xml-инъекций и т.д.) состоит в том, чтобы найти приложение второго вида и заставить его выполнить некоторое полезное нам действие, возможность которого не планировалась программистом.
К примеру, есть некий скрипт articles.php. И туда методом Get передается значение параметра id.
Кодер когда писал свое приложение думал примерно так:
- "Кроче, берем id из адресной строки. Пихаем иво в скуль-запрос. Если в базе есть такой id, то выводим страницу, которая к энтому Id прикручена, а ежеле нету, то тохда ибись оно в рот и ничово не выводем."
PHP:
<?php
//articles.php
include("db_config");
$id = $_GET['id'];
$sql = "SELECT * FROM articles WHERE id = '$id' ";
$result = mysql_query($query) or die(mysql_error());
$row = mysql_fetch_array($result) or die("НИЧОВО НЕТУ!!!");
//...Но любой результат можно свести к одному из трех вариантов:
- Пустой ответ
- Нормальный ответ
- Ошибка
Очевидно, что в суровой действительности веб-приложение ведет себя не совсем так, как это представлялось кодеру в его влажных мечтах. И по сути, в последнем варианте параметр/значение мы уже провели небольшую SQL-инъекцию.
Остается дело за малым - раскрутить эту самую инъекцию (попробовать вывести данные из бд, прочитать файлы, залить шелл и т.д.)
Стоит сразу отметить 2 нюанса:
- Если ошибки не выводятся, это совсем не значит, что в приложении нет SQL-инъекции.
- Помните, что есть существенная разница между выводом ошибок от интерпретатора и выводом ошибок от СУБД.
Виды SQL-инъекций
SQL-инъекции разделяют на множество видов
1) По типу переменной:
Integer (целочисленная). Параметр не обрамлен кавычками:
Код:
SQL-инъекции разделяют на множество видов
1) По типу переменной:
Integer (целочисленная). Параметр не обрамлен кавычками:String (строковая). Параметр обрамлен кавычками:
Код:
SELECT * FROM articles WHERE id = ' $id ';
SELECT * FROM `$articles` WHERE id = 123 ;
SELECT * FROM articles WHERE id = " $id ";2) По типу SQL-запроса и месту инъекции в запросе. В теории, инъекция может быть в абсолютно любом месте абсолютно любого SQL-запроса, если туда попадают недостаточно фильтруемые данные. Чаще всего инъекции находят в SELECT (отдельно выделяют инъекции после order by, потому как их реализация чуть сложнее), реже в UPDATE, INSERT, DELETE. Поэтому можно встретить разделение - Update based, Insert based и т.д.
3) Данные в SQL-запрос могут попадать через Get, Post, Cookie, HTTP заголовки (реферрер, юзерагент, или еще что-то, на что хватит фантазии у программиста).
Также стоит отметить такой класс инъекций как Second order injection. Это когда данные попадают в SQL-запрос не напрямую от пользователя (get, post, cookie, http headers), а из БД, из файла, от самого Аллаха или еще из какого места куда мы могли ранее ввести данные.
К примеру, есть форма регистрации (все очень условно):
PHP:
<?php
//Форма регистрации
$username = mysql_real_escape_string($_POST['username']);
$pass = mysql_real_escape_string($_POST['pass']);
$sql = "INSERT INTO users (username, pass) VALUES ('$username','$pass') ";
mysql_query($query) or die('Хакир, игрой в доту!');Данные экранируются, SQL-инъекции нет. Далее, форма авторизации:
PHP:
<?php
//Форма аутентификации. Логин попадает в сессию
$username = mysql_real_escape_string($_POST['username']);
$pass = mysql_real_escape_string($_POST['pass']);
$sql = "SELECT * FROM users WHERE username='$username' AND pass='$pass'";
$result = mysql_query($query) or die('Хакир, учи уроке!');
$row = mysql_fetch_row($result);
$_SESSION['username'] = $row['username'];И наконец форма для смены пароля:
PHP:
<?php
//Форма смены пароля.
$username=$_SESSION['username'];
$password = mysql_real_escape_string($_POST['pass']);
$new_pass = mysql_real_escape_string($_POST['new_pass']);
$sql = "UPDATE users SET PASSWORD='$new_pass' where username='$username' and password='$password' ";
$result = mysql_query($query) or die('Пативэн выехал...');Тут тоже нет SQL-инъекции. Но! Если зарегистрировать пользователя с логином "admin' #", то можно сменить пароль для пользователя "admin", не зная его действующий пароль (проверьте на досуге). Это и будет Second order SQL-injection.
4) По типу SQL-инъекции:
4.1) Union-based. Инъекция в SELECT запросе, вывод данных из БД производится с помощью оператора UNION. Этот метод работает, когда веб-приложение напрямую возвращает результат вывода команды SELECT на страницу (поэтому без разницы, включен вывод ошибок или нет).
Код:
http://example.com/?id=9999.9' union select 1,2,3,4,5,6,7 --+4.2) Error-based (double query). Если использовать UNION не получается (нет колонки для вывода или инъекция в UPDATE, INSERT или DELETE), то можно вывести данные из базы искусственно вызывая ошибки.
Например такой запрос:
Код:
SELECT COUNT(*) FROM (SELECT 1 UNION SELECT 2 UNION SELECT 3)x GROUP BY MID(user(), FLOOR(RAND(0)*2), 64)Вызовет ошибку, в отчете о которой мы увидим данные, которые нам были нужны:
- Duplicate entry 'root@localhost' for key 1
4.3) Blind-based (boolean based). Если данные нельзя вывести через union, а ошибки никак не выводятся, то скорее всего мы имеем дело со слепой инъекцией.
Как вы помните, приложение может вернуть либо нормальный результат, либо пустой, либо ошибку. Ошибки в данном случае подавляются. Поэтому мы можем использовать только, что пустой ответ это false, а нормальный ответ - true.
И это только чтобы узнать, что первый символ в имени пользователя базы данных это "r" (114 это ascii-код этого символа).
4.4) Time-based (double blind). А теперь представьте, что SQL-инъекция есть, но результат отдаваемый веб-приложением, не меняется вообще никак. Нельзя как-то выделить, что будет false, а что будет true? Что делать тогда? Использовать временные задержки.
Там где будет True, сервак будет тупить 10 секунд, прежде чем вернуть страницу. В остальном все идентично обычным слепым (boolean based) инъекциям.
Чтобы как-то уложилось в голове (вывод ошибок - от СУБД!):
Теперь, по мере изучения дальнейших материалов, вы, надеюсь, не будете путаться в классификации инъекций. Если что-то было непонятно, вы с легкостью восполните пробелы в знаниях, изучив соответствующие материалы.
Материалы:
SQL
- http://rutracker.org/forum/viewtopic.php?t=4621035
- http://rutracker.org/forum/viewtopic.php?t=129425
- Lynn Beighley. Head first SQL
- Алан Бьюли. Изучаем SQL
- http://dev.mysql.com/doc/
- https://msdn.microsoft.com/ru-ru/library/bb545450.aspx
- http://www.oracle.com/technetwork/ru...ion/index.html
- https://www.sqlite.org/docs.html
- http://postgresql.ru.net/manual/
- https://rdot.org/forum/
- https://rdot.org/forum/showthread.php?t=124
- http://forum.antichat.ru/threadedpost3817395.html (1500 страниц практических примеров)
- http://www.securityidiots.com/Web-Pe...SQL-Injection/
- PentestIT - SQL инъекции
- http://www.securitytube.net/tags/SQLi
- http://www.websec.ca/kb/sql_injection
- http://ptsecurity.ru/download/PT-dev...-Injection.pdf
- http://pentestmonkey.net/category/ch.../sql-injection
- http://www.sqlinjectionwiki.com/
- http://sqligenerator.altervista.org/index.php (генератор ссылок на уязвимые ресурсы)
- Юрий Жуков. Основы веб-хакинга
- Justin Clarke. SQL injection. Attacks and Defense.
Манипуляции с базой данных. В базе данных может быть что угодно.
Если у нас есть возможность читать данные из бд, мы можем узнать много интересного:
- Логины/пароли
- Почтовые ящики
- Кредитки и личные данные
- Токены (например для восстановления пароля)
- Переписки
- Скрытый контент
- Информация о заказах
- Цифровые товары
- Коды запуска ядерных боеголовок
- (вставьте свой вариант)
Запись в файл/чтение файлов. Если звезды сложились удачно и у нас есть достаточно прав, известен абсолютный путь к файлам и не фильтруются кавычки, мы можем с легкостью залить шелл. Читать файлы можно даже при ограниченных правах. Например, можно прочесть из конфига логин/пароль от соединения с базой данных, и если повезет, подключиться напрямую. Если очень повезет - узнать пароль от фтп (в конфигах jooml'ы иногда хранится).
SiXSS. Union based и Error based инъекции позволяют провести XSS атаку.
этого, вместо вывода данных из таблицы, мы пишем необходимый нам js-код:
HTML:
?id=-1' union select 1,2,3,4,5,<script>alert('xss');</script>,6,7,8 --+Но в отличии от обычной пассивки, она способна обойти защиту большинства браузеров (которые хавают обычные пассивки на раз-два):
Код:
?id=-1' union select 1,2,3,4,5,unhex('3c7363726970743e616c657274285c277 873735c27293b3c2f7363726970743e'),6,7,8 --+Обход авторизации. Если уязвимость спряталась в форме авторизации, то вам не нужно будет знать пароль (а иногда и логин) для входа под учеткой другого пользователя/администратора.
SQLi + Denial of Service. С помощью одного нехитрого запроса можно повалить сайт к ебени-матери (например используя вложенный Benchmark).
Практика.
Чтобы действительно вьехать в тему, недостаточно просто изучить теорию.
Нужно обязательно практиковаться:
- Ковырять заведомо уязвимые скрипты (DVWA, Mutillidae и подобные).
- Разбирать эксплоиты.
- Разбирать чужие взломы (отлично подойдут различные хак ресурсы).
- Участвовать в конкурсах и CTF.
Автоматизация.
Частенько мелькают сообщения на андергрант-форумах, дескать илита не пользуется софтом, а раскручивает все ручками. Возможно где-то и есть уникумы, которые time based скулю раскручивает с секундомером в руках, в качестве браузера используют telnet на 80 порт, а md5 хеши брутфорсят с помощью калькулятора, карандаша и листа A4, но мы к такой илите не относимся (мы вообще к илите не относимся).
Как я уже советовал вам ранее, поставьте Burp Suite. Хотя вы можете использовать любые другие отладочные прокси (Fiddler, Charles и т.д.), это уже скорее дело привычки, но Burp Suite все-таки заточен именно под поиск и эксплуатацию уязвимостей. Берем http-запрос, отправляем в Intruder, сразу смотрим результат. Шик же.
Если говорить об автоматизации sql-инъекций, то тут две софтины впереди планеты всей.
havij - утилита must have для школо-хеккера (а также сценарной детки). Многие из тех кто используют эту программу, не знают, как провести атаку, если уязвимый параметр передается Post'ом или в куках. И это при том, что есть вполне сносная справка на сайте.
Любознательным товарищам будет полезно запустить havij через прокси (тот же burp suite или fiddler), чтобы увидеть и понять, как именно работает havij. Софт заточен под винду, имеет free и pro версию. "Крякнутые" версии практически всегда с чем-то склеены, и не обладают полным функционалом.
Определенно, есть много объективных причин (и все на поверхности), почему софт так популярен в массах. Есть масса аналогов, Pangolin, SQLi-helper и других, которые даже до havij не всегда дотягивают. Те же яйца, вид сбоку.
sqlmap - на сегодняшний день, это лучший софт, для автоматизации SQL-инъекций. Любой пацык на районе подтвердит. Правда, нужно установить питон. И программа консольная (хотя и GUI обертку легко найти). Но это тока шобы отпугивать всякую шерсть, которая не сечет фишку.
Чтобы подтянуть знания по SQL-инъекциям, можно посмотреть исходники sqlmap (ну или поснифать запросы через веб-прокси).
Алгоритм для автоматизации простой:
- Burp Proxy. Сохраняем интересный запрос в файл request.txt (ПКМ -> Copy to file)
Код:
sqlmap.py -r request.txtЭто что касается автоматизации тестирования на sql-инъекции на одном сайте. Если вам нужно чекнуть на скули несколько десятков (сотен, тысяч) сайтов, то алгоритм, приведенный выше, вряд ли подойдет (если только вы не Дункан Маклауд).
Веб хакинг [часть 1]
Веб хакинг [часть 2]
Веб хакинг [...]
Последнее редактирование:
