Тест-драйв профессии «Пентестер»

Что такое SQL-инъекция: как ввод попадает в SQL-запрос

SQL-инъекция возникает на стыке веб-приложения и базы данных. Любое веб-приложение устроено по одной схеме. Есть клиент: браузер или мобильное приложение. Есть веб-сервер, который принимает запросы и отдаёт ответы. И есть база данных, где лежат данные приложения: список фильмов, пользователи, их почта. Логику между сервером и базой пишет разработчик, и снаружи она не видна.

Проблемы начинаются там, где значение из запроса попадает в SQL. Поиск по фильму вида index.php?name=Терминатор часто превращается в запрос, где параметр просто склеивается со строкой: SELECT * FROM movies WHERE title LIKE '%Терминатор%'. Твоё слово встало внутрь чужого запроса.

Склейка строк и есть корень почти всех SQL-инъекций.

Как найти SQL-инъекцию: кавычка, которая ломает запрос

Самый первый тест на SQL-инъекцию: поставить в параметр одну кавычку. Тогда количество кавычек в запросе становится нечётным, база не может разобрать синтаксис и возвращает ошибку. Если приложение написано неаккуратно, эта ошибка прилетает прямо тебе в ответ.

Дальше проверка простая. Поставь вторую кавычку: количество снова чётное, и ошибка пропадает.

Параметр, который ломается на одной кавычке и чинится на двух, почти наверняка уязвим.

Но перед тем как что-то подставлять, помни про границы работы пентестера.

Мы работаем только по документам от заказчика, которые разрешают тестирование. Ставить кавычку в чужой сайт просто так незаконно.

Кирилл Николаев

Почему OR 1=1 опасен в пентесте

Конструкция OR 1=1 делает условие всегда истинным, поэтому запрос возвращает все строки. В методичках по SQL-инъекциям её советуют первой, и именно поэтому с ней легко наделать беды.

Твой ввод может попасть не только в SELECT, но и в UPDATE, DELETE или INSERT где-то дальше по коду, которого ты не видишь.

Показательная история. Начинающему пентестеру дали проверить банк. Он вписал OR 1=1 в форму логина и попал в админ-панель. Обрадовался, но не заметил, что приветствие на главной странице онлайн-банка, с последним входом и IP-адресом, строилось на запросе записи. Его ввод переписал эту запись сразу для всех клиентов банка, и в поддержку посыпались звонки, что все вошли с одного IP. На рабочих системах так не делают.

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

Кирилл Николаев

Как пользоваться Burp Suite: перехват и повтор запросов

Для поиска уязвимых параметров в веб-приложении хватает одной утилиты, Burp Suite. Это прокси между браузером и сервером: каждый запрос сначала проходит через него, и там его можно прочитать и изменить. В отличие от инструментов, которые только смотрят трафик, Burp даёт его менять и отправлять заново десятки и сотни раз.

Для работы хватает двух частей:

• HTTP history: вся история запросов, которые сделал браузер.
• Repeater: отправляешь один и тот же запрос много раз, правишь любой заголовок или параметр, сразу видишь ответ.

Для HTTPS нужно поставить сертификат Burp или работать во встроенном браузере, где он уже настроен. Расширение Hackvertor кодирует полезную нагрузку, чтобы пробелы и спецсимволы не разорвали HTTP-запрос: обычный пробел разделяет части строки запроса.

UNION-инъекция: как подобрать число столбцов

UNION присоединяет к запросу разработчика твой собственный SELECT. Чтобы это сработало, слева и справа должно быть одинаковое количество столбцов, а в части баз данных, включая PostgreSQL, ещё и одинаковые типы. Порядок такой:

1. 1

   Найди количество столбцов через ORDER BY. Подставляешь ORDER BY 1, потом 2, 3 и так далее, пока не получишь ошибку. Последнее рабочее число и есть количество столбцов.

2. 2

   Подгони типы. Заполни свой SELECT значениями NULL: NULL подходит под любой тип.

3. 3

   Освободи вывод. На страницу часто выводится только первая строка результата, поэтому сделай так, чтобы часть запроса от разработчика не вернула ничего: подставь, например, несуществующее имя пользователя. Тогда отобразится ровно то, что ты добавил через UNION.

Как достать структуру базы данных через information_schema

Когда данные уже читаются, разберись, с чем имеешь дело:

1. 1

   Узнай СУБД. Функция version() в PostgreSQL возвращает и СУБД, и операционную систему: так сразу видно, что перед тобой, например, PostgreSQL на Debian.

2. 2

   Получи список таблиц. Мета-база information_schema хранит информацию обо всех таблицах, колонках и их типах, а information_schema.tables отдаёт имена таблиц.

3. 3

   Получи колонки. information_schema.columns с условием по имени таблицы отдаёт её колонки.

В PostgreSQL версии 9 и выше есть функция string_agg, которая склеивает много строк в одну: это удобно, когда на страницу выводится только одна строка. Что именно получится прочитать, зависит от привилегий пользователя базы.

Stacked-запросы и выполнение команд ОС через PostgreSQL

Внутри SELECT можно вложить только другой SELECT. Stacked-запросы, самый опасный вид SQL-инъекции, снимают это ограничение: точка с запятой завершает текущий запрос и начинает новый. После запроса разработчика можно выполнить DROP, UPDATE, INSERT, что угодно.

Работает это не везде, а зависит от языка, драйвера и базы данных. В связке PostgreSQL с PHP stacked-запросы проходят. Безобидная проверка строится на времени: добавляешь ; SELECT pg_sleep(3), и ответ приходит на три секунды позже. Если задержка растёт вместе с числом, инъекция подтверждена.

Дальше возможностей больше. Через stacked-запросы можно добавить себя в таблицу администраторов или сменить пароль. PostgreSQL идёт ещё дальше: COPY FROM PROGRAM выполняет команду операционной системы. Схема такая: создать таблицу, скопировать в неё вывод команды, затем прочитать таблицу обычным SELECT. Так получается выполнение кода на сервере. Чтение и запись файлов идут через COPY, в MySQL через LOAD_FILE и INTO OUTFILE, в MSSQL есть хранимая процедура xp_cmdshell, которая по умолчанию выключена и требует прав и переконфигурации. Везде упираешься в привилегии пользователя базы.

Защита от SQL-инъекций: prepared statements и ORM

Главная защита от SQL-инъекций это prepared statements, подготовленные (параметризованные) запросы. В них запрос с подстановками в виде знаков вопроса компилируется заранее, а значения пользователя едут отдельно. Ввод уже не может изменить структуру запроса, и это закрывает почти все инъекции.

ORM тоже помогает, но у него есть слабые места. Раньше он склеивал значения в таких местах, как ORDER BY или имена колонок, и туда пользовательский ввод всё же просачивался. Крупные фреймворки такие ошибки чинят быстро. Очень редко уязвимость в самом драйвере базы позволяет обойти даже подготовленные запросы, но это исключение.

Пиши prepared statements, и на 99,9 процента защитишься от SQL-инъекций. Это самый действенный способ защиты.

Кирилл Николаев

Как стать пентестером и где тренироваться

Направлений в пентесте много: внутренние сети, веб, мобильные приложения, реверс. Выбирай то, что увлекает. Если понимаешь веб, у тебя уже есть преимущество на старте: ломай учебные стенды, учись и иди на собеседования к тем, кто тестирует веб. Работодатели хотят понимания: что за утилиту ты запускаешь и почему работает уязвимость. Сертификаты им почти не нужны.

Сам метод простой: видишь параметр, ставишь кавычку; заметил странное поведение, копаешь глубже. Чтобы довести это до автоматизма, тренируйся на системах, созданных для практики.

• Web Security Academy от создателей Burp: открытая платформа с тренировочными заданиями, из них шестнадцать по SQL-инъекциям, с разборами.
• Старый набор уязвимых заданий, который поднимается в Docker: выглядит грубо, зато очень понятно показывает, где именно работает SQL.

Держи свои заметки: детали всё равно забываются, а записанное бьёт память.