Тёмная лаборатория пентестера, освещённая только мониторами. На изогнутом экране — терминал SQLMap с выводом слепой SQL-инъекции и дампом хешей паролей.


На пентесте интернет-банка мне попалась blind SQL-инъекция в cookie-параметре TrackingId. Ручная верификация заняла три часа - ответы сервера различались одним символом в HTML, и я сидел, как сапёр, сравнивая байты. SQLMap подтвердил инъекцию за восемь минут через --level=3 (без этого флага cookie-параметры вообще не тестируются) и вытащил хеши паролей из PostgreSQL за следующие двадцать. Инструмент сэкономил день работы, но только потому, что я знал, какие флаги передать, как оформить scope и зачем открывать Burp Suite перед запуском. Эта статья - про всё, что происходит вокруг самого запуска, и про те вещи, которые ни один --help не объяснит.

Место SQLMap в цепочке атаки​

SQLMap - не сканер уязвимостей. Это инструмент подтверждения и эксплуатации SQL-инъекций, который занимает конкретное место в kill chain пентеста веб-приложений. Путать одно с другим - верный способ получить шум в логах и ноль результата. Подробнее - в нашем обзоре пентест веб-приложений.

В терминах MITRE ATT&CK инструмент покрывает несколько тактик одновременно:
  • Initial Access - Exploit Public-Facing Application (T1190): эксплуатация SQL-инъекции в публично доступном веб-приложении для получения начального доступа
  • Collection - Databases (T1213.006): перечисление схем, извлечение данных из таблиц, полный дамп содержимого
  • Credential Access - Brute Force (T1110): встроенный брутфорс извлечённых хешей паролей по словарям
  • Persistence - Web Shell (T1505.003): через флаг --os-shell при наличии привилегий на запись в файловую систему сервера
По OWASP Top 10 (2021), Injection-уязвимости сидят на позиции A03:2021 - связанные с инъекциями CWE имеют второе по частоте количество вхождений среди протестированных приложений. Кто думает, что инъекции остались в 2015-м - пусть посмотрит статистику.

В реальном пентесте цепочка выглядит так: разведка и обнаружение потенциальных точек инъекции (ручной анализ, Burp Scanner, анализ ответов сервера) → подтверждение инъекции (SQLMap или ручная проверка) → эксплуатация (дамп данных, определение привилегий, эскалация) → документирование для отчёта. SQLMap закрывает второй и третий этапы, но первый - всегда за пентестером. Запуск SQLMap без предварительной ручной разведки генерирует шум в логах, повышает риск блокировки по WAF и тратит время на проверку заведомо неинъектируемых параметров.

[Применимо: внешний пентест (black box, grey box), тестирование веб-приложений на уязвимости]

Юридические предусловия: что оформить до первого запуска sqlmap​

Не раздел «для галочки». SQLMap генерирует сотни, иногда тысячи запросов к целевому серверу. Каждый из них может квалифицироваться как неправомерный доступ к компьютерной информации по ст. 272 УК РФ. Если целевая система - часть критической информационной инфраструктуры (КИИ), вступает ст. 274.1 УК РФ - неправомерное воздействие на КИИ, санкции до 10 лет. Надзор за выполнением требований по защите КИИ - ФСТЭК в рамках ФЗ-187 (ст. 14).

Что должен содержать scope-документ​

Договор на легальный пентест - ваша юридическая защита. До первого запуска sqlmap зафиксируйте письменно:
  1. Перечень целевых систем - конкретные URL, IP-адреса, домены. Формулировка «весь периметр заказчика» - юридически размытая и опасная.
  2. Разрешённые методы тестирования - явное указание на допустимость автоматизированного тестирования SQL-инъекций. Если в договоре написано «ручное тестирование», запуск SQLMap формально выходит за рамки scope.
  3. Временные рамки - даты и часы, когда тестирование разрешено. SQLMap в 3 часа ночи без согласования - нарушение scope даже при наличии договора.
  4. Контактное лицо на стороне заказчика - кому звонить, если тяжёлые time-based запросы на --risk=3 положили production-базу.
  5. Исключения - что не трогать: production-данные реальных пользователей, конкретные endpoints, определённые базы данных.
В Bug Bounty платформа (HackerOne, Bugcrowd) публикует scope, и запуск автоматизированного сканера в зоне «out of scope» - бан и потеря репутации. На большинстве программ SQLMap допустим только в отношении параметров, которые вы уже вручную подтвердили как потенциально уязвимые.

Требования к окружению​

Перед первым запуском убедитесь, что рабочая среда готова.

Системные требования:
  • ОС: Linux (Kali/Ubuntu - рекомендуется), macOS, Windows
  • Python 2.7 или 3.x (в Kali предустановлен)
  • RAM: 512 МБ хватит для SQLMap, 4 ГБ и более - если параллельно крутится Burp Suite
  • Сетевое подключение к целевой системе (VPN при внутреннем пентесте)
  • Burp Suite Community или Professional - для перехвата и сохранения HTTP-запросов
Установка из репозитория - проект активно поддерживается, CI/CD через GitHub Actions, совместимость с Python 2.7 и 3.x на всех платформах:
Bash:
git clone --depth 1 https://github.com/sqlmapproject/sqlmap.git sqlmap-dev
cd sqlmap-dev
python3 sqlmap.py --version
Не берите версии из пакетных менеджеров дистрибутивов - они отстают на месяцы. Клонирование из GitHub гарантирует актуальную версию с последними tamper-скриптами и пейлоадами.

Рабочий процесс: от Burp Suite до полного дампа​

Команда sqlmap -u "http://target/page.php?id=1" работает на CTF-стендах и в туториалах. В реальном пентесте запросы содержат cookies, CSRF-токены, кастомные заголовки и авторизацию - всё это надо передать инструменту корректно. Рабочий процесс начинается в Burp Suite.

Перехват и передача запроса через -r

[Применимо: внешний и внутренний пентест, любая СУБД, black box и grey box]

Шаг 1. В Burp Suite перехватите запрос с подозрительным параметром. Подозрительность определяется вручную: параметр передаётся в SQL-запрос на стороне сервера (ID записи, фильтр, сортировка, поисковая строка).

Шаг 2. Правой кнопкой по запросу → «Copy to file» (или откройте вкладку Request, выделите весь raw-запрос через Ctrl+A → Ctrl+C и вставьте в текстовый файл). Сохраните как request.txt. Убедитесь, что файл содержит plaintext HTTP-запрос без XML-обёртки Burp - иначе sqlmap не распарсит.

Шаг 3. Скармливаем файл sqlmap:
Код:
sqlmap -r request.txt -p "id" --dbms=MySQL --batch --level=3 --risk=2 --random-agent
Каждый флаг тут не для красоты:

-r request.txt - полный HTTP-запрос из файла. SQLMap получает cookies, заголовки авторизации, Content-Type без ручной настройки каждого параметра.

-p "id" - явное указание тестируемого параметра. Без него SQLMap полезет проверять все параметры запроса, что увеличивает время и трафик в разы.

--dbms=MySQL - если СУБД определена через fingerprinting или ошибки сервера, указание --dbms сокращает количество тестовых пейлоадов в 4-5 раз. SQLMap не тратит время на пейлоады для PostgreSQL, Oracle и MSSQL.

--batch - автоматический ответ «Yes» на все интерактивные вопросы. Критичен для скриптовой автоматизации, но опасен если не понимаете, на что соглашаетесь: SQLMap спрашивает «хотите ли попробовать расширенные пейлоады» - с --batch ответ всегда «да».

--level=3 - глубина проверки. Level 1 (по умолчанию) проверяет только GET и POST. Level 2 добавляет Cookie. Level 3 - User-Agent и Referer. Level 5 - проверяется абсолютно всё. На реальных пентестах запускайте не ниже 3.

--risk=2 - степень агрессивности. Risk 1 - только безвредные запросы. Risk 2 добавляет time-based тесты (могут замедлить сервер). Risk 3 - запросы с OR в контексте UPDATE/DELETE, которые способны модифицировать или удалить данные. Это та граница, за которой можно положить production.

--random-agent - подменяет User-Agent на случайный из реального браузера. Дефолтный User-Agent SQLMap содержит строку sqlmap - любой приличный WAF его заблокирует мгновенно.

Последовательность эксплуатации после обнаружения SQL-инъекций​

Когда SQLMap подтвердил инъекцию и определил тип (boolean-based blind, time-based blind, error-based, UNION, stacked queries или out-of-band), дальше - пошаговое извлечение:
  1. Перечисление баз данных - флаг --dbs. SQLMap покажет все доступные базы на сервере.
  2. Перечисление таблиц - -D имя_базы --tables. Структура конкретной базы.
  3. Перечисление столбцов - -D имя_базы -T имя_таблицы --columns. Структура интересующей таблицы.
  4. Дамп данных - -D имя_базы -T имя_таблицы -C "username,password" --dump. Извлечение конкретных столбцов. Для отчёта хватит первых 5-10 записей - полный дамп production-базы выходит за рамки большинства scope-документов.
  5. Проверка привилегий - --is-dba. Определяет, является ли текущий пользователь БД администратором. Если да - доступны --file-read, --file-write, --os-shell.

Поведение sqlmap для разных СУБД​

Ключевой параметр sqlmap - --dbms. Без него инструмент перебирает пейлоады для всех поддерживаемых баз. Но поведение и возможности на разных СУБД принципиально отличаются:

СУБДStacked queriesЧтение/запись файловOS shellКритичные предусловия
MySQLОбычно недоступны (mysqli_query/PDO без эмуляции не поддерживают multi-statement; возможны только при mysqli_multi_query или PDO с ATTR_EMULATE_PREPARES=true)Через LOAD_FILE / INTO OUTFILEЧерез UDF-библиотекуТребуется FILE privilege у пользователя БД
PostgreSQLДаЧерез pg_read_file / COPYЧерез PL/PythonPL/Python расширение должно быть установлено
MSSQLДаЧерез xp_cmdshellНативно через xp_cmdshellxp_cmdshell по умолчанию отключён, нужна роль sysadmin
SQLiteНетНетНетДоступен только дамп данных

[Предусловия: для file read/write и OS shell нужны привилегии DBA. Проверяйте через --is-dba до попытки. На modern-инфраструктуре с hardened-конфигурацией привилегии DBA для пользователя веб-приложения - редкость.]

Почему SQLMap молчит: разбор типичных провалов​

Новички запускают SQLMap, видят «all tested parameters do not appear to be injectable» и решают, что уязвимости нет. По моему опыту - в половине таких случаев проблема не в отсутствии инъекции, а в кривой конфигурации инструмента.

Забытый --cookie при работе через -u. Приложение требует авторизации, а запрос через -u не содержит session cookie. SQLMap тестирует страницу логина или получает 403. При работе через -r cookies подтягиваются из файла автоматически - одна из причин, почему -r предпочтительнее.

Дефолтный --level=1. По умолчанию проверяются только GET и POST параметры. Инъекция в Cookie, User-Agent, Referer, X-Forwarded-For остаётся невидимой. Та самая инъекция в TrackingId cookie из моего примера - при level 1 SQLMap не нашёл бы ничего.

Неверный или незаданный --dbms. Без указания СУБД инструмент перебирает пейлоады для всех баз, генерируя огромный трафик. WAF или IDS блокируют по rate limit раньше, чем SQLMap дойдёт до нужного пейлоада.

Нестабильный контент страницы. SQLMap сравнивает ответы для определения boolean-based инъекций. Если на странице есть динамические элементы - timestamp, рекламные баннеры, рандомные CSRF-токены - инструмент не может отличить «истинный» ответ от «ложного». Решение: --string="фрагмент_текста_при_true" или --not-string="фрагмент_при_false", или --code=200 (если отличаются HTTP-коды ответов).

Блокировка по User-Agent. Дефолтный User-Agent SQLMap содержит строку sqlmap/версия - сигнатура для любого WAF. Решается через --random-agent.

Прокси или CDN меняют ответы. Cloudflare, AWS CloudFront и подобные сервисы могут кешировать ответы или подменять содержимое. SQLMap получает один и тот же ответ независимо от пейлоада и считает параметр неинъектируемым. Решение: использование прямого IP сервера (если доступен) или --delay для обхода кеширования.

Обход WAF: tamper-скрипты и стратегии автоматизации SQL-инъекций​

[Применимо: внешний пентест, где WAF стоит между тестером и приложением. На внутреннем пентесте WAF обычно не мешает.]

Tamper-скрипты модифицируют SQL-пейлоады «на лету», обходя сигнатурные правила файрволов. SQLMap содержит более 50 встроенных скриптов - полный список доступен через sqlmap --list-tampers.

Наиболее результативные комбинации из практики:

Против фильтрации пробелов - space2comment заменяет пробелы на /**/, space2morecomment использует расширенные комментарии. Базовая комбинация: --tamper=space2comment,randomcase.

Против фильтрации ключевых слов - randomcase рандомизирует регистр: SeLeCt, UnIoN. Скрипт between заменяет операторы сравнения: > превращается в NOT BETWEEN 0 AND. Скрипт charencode применяет URL-кодирование ко всему пейлоаду.

Комплексный обход для агрессивного тестирования: --tamper=space2comment,randomcase,between --random-agent --delay=2 --level=5 --risk=3. Флаг --delay=2 добавляет двухсекундную паузу между запросами, снижая вероятность блокировки по rate limiting. Медленнее - зато не прилетит бан на третьем запросе.

Стратегия подбора: не угадывайте, анализируйте​

Универсальной комбинации tamper-скриптов не существует. Подбор - итеративный процесс:
  1. Запустите SQLMap через прокси (--proxy=http://127.0.0.1:8080) и в Burp Suite посмотрите, какие именно запросы блокируются WAF.
  2. Проанализируйте ответ - какой паттерн вызвал срабатывание: ключевое слово (UNION, SELECT), символ (', --), длина запроса или частота.
  3. Подберите tamper-скрипт, модифицирующий заблокированный паттерн.
  4. Повторите тест. Если WAF блокирует новый паттерн - добавьте ещё один скрипт в цепочку.

Когда tamper-скрипты не работают​

Работает против: сигнатурных WAF - ModSecurity с базовыми CRS-правилами, устаревшие конфигурации Imperva, AWS WAF с дефолтными managed rules.

Не работает против: поведенческих WAF и ML-моделей - advanced-tier Cloudflare, F5 ASM с Machine Learning, Wallarm в режиме поведенческого анализа. Эти системы анализируют не конкретные строки, а аномальное поведение: частоту запросов, энтропию значений параметров, структуру HTTP-сессии. Тут никакой tamper не спасёт.

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

Ограничения SQLMap: когда инструмент не поможет​

Обнаружение SQL-инъекций и их эксплуатация через SQLMap - не равно «пентест веб-приложения». Инструмент решает одну задачу хорошо, но за его пределами остаётся многое. Понимание границ отличает эксперта от скрипт-кидди.

Сравнение: SQLMap против ручной эксплуатации​

КритерийSQLMapРучная эксплуатация
Скорость полного дампаМинуты–часыЧасы–дни
Нестандартная бизнес-логикаНе справляется (многоступенчатые формы, HMAC-подпись)Полная адаптация
Шум в IDS/SIEMВысокий (сотни–тысячи запросов)Контролируемый
JSON/GraphQL APIОграниченная поддержка через workaroundПолная
Stored-инъекцииНе обнаруживает автоматическиГибкий подход
Необходимый уровень навыковСредний (знание флагов и логики)Высокий (SQL, HTTP, СУБД-специфика)
ДокументированиеАвтоматическое сохранение в output/Ручное, но контролируемое

Конкретные сценарии, где SQLMap бесполезен​

Stored (хранимые) инъекции - пейлоад вводится на одной странице, срабатывает на другой (например, в админ-панели). SQLMap не отслеживает эту связь без явного указания второй точки наблюдения.

WebSocket и gRPC - инструмент работает с HTTP/HTTPS. Для WebSocket-эндпоинтов нужен кастомный прокси-обёртка или ручная эксплуатация.

Anti-CSRF токены со сложной логикой - SQLMap поддерживает --csrf-token и --csrf-url, но если генерация токена зависит от предыдущего ответа, привязана к временной метке или требует JavaScript-вычислений, автоматизация ломается.

Кастомное шифрование параметров - если параметр id передаётся в Base64 или AES, SQLMap не знает, как декодировать значение перед инъекцией. Нужен кастомный tamper-скрипт или прокси-обёртка, обрабатывающая кодирование.

Second-order инъекции через разные HTTP-методы - данные вводятся через POST, но инъекция срабатывает при GET-запросе к другому endpoint. SQLMap не моделирует такие цепочки без ручной помощи.

Что фиксировать в отчёте по результатам sqlmap​

Вывод SQLMap - не отчёт. Это сырые данные, которые нужно структурировать для заказчика. Минимум для каждой найденной инъекции:
  1. URL и параметр - точный endpoint и имя параметра с указанием HTTP-метода (GET/POST/Cookie/Header).
  2. Тип инъекции - boolean-based blind, time-based blind, error-based, UNION, stacked queries. SQLMap указывает тип в выводе.
  3. СУБД и версия - автоматически определяется SQLMap, дополнительно проверяется через --banner.
  4. Импакт - какие данные доступны, какой уровень привилегий (DBA или обычный пользователь), возможность чтения/записи файлов, возможность выполнения команд ОС.
  5. Извлечённые данные как доказательство - первые 5-10 записей. Полный дамп production-базы - за рамками легального пентеста, если это не оговорено в scope отдельно.
  6. Рекомендации по устранению - параметризованные запросы (prepared statements), ORM с корректной конфигурацией, WAF как дополнительный уровень защиты (не замена для исправления кода).
Скриншоты команд с выводом - обязательны. Логи из директории output (по умолчанию ~/.local/share/sqlmap/output/) приложите как артефакты отчёта.

Чеклист: запуск SQLMap на легальном пентесте​

Перед каждым запуском пройдите по списку:
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Среди пентестеров, с которыми я работаю, основная ошибка - не техническая. SQLMap запускается до подписания scope. Или с --risk=3 на production без предупреждения заказчика. Или в три часа ночи без уведомления SOC. Каждый из этих промахов - потенциальные проблемы: от расторжения контракта до возбуждения дела по ст. 272 УК РФ. Инструмент не защищает от неправильных решений оператора.

Я убеждён: 80% проблем с SQLMap - процессные, а не технические. Инструмент делает ровно то, что просят. Проблема в том, что его просят о неправильных вещах в неподходящее время.

Начинающие пентестеры гонятся за дампами и --os-shell, пропуская юридическую подготовку и ручную верификацию. Я видел, как джуниоры запускали SQLMap на production-базе с --risk=3 и ломали таблицу пользователей через инъекцию в UPDATE-запрос - потому что не прочитали в документации, что risk 3 добавляет OR-условия в контексте модифицирующих операций. Видел, как результат SQLMap принимали за единственный вектор атаки, хотя рядом лежал stored XSS с куда большим импактом.

SQLMap - инструмент подтверждения и эксплуатации того, что вы уже нашли руками. Не инструмент поиска, не серебряная пуля, не замена знанию SQL. Если не можете объяснить, как работает boolean-based blind инъекция без инструмента, если не понимаете разницу между UNION SELECT NULL,NULL,NULL и UNION SELECT 1,2,3 - автоматизация не ускорит работу, а создаст ложное чувство контроля. Попробуйте провернуть слепую инъекцию вручную через curl - и тогда станет понятно, что именно SQLMap делает за вас и почему каждый флаг имеет значение.
 
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab

Похожие темы

🚀 Первый раз на Codeby?
Гайд для новичков: что делать в первые 15 минут, ключевые разделы, правила
Начать здесь →
🧭 Навигатор · ИБ 2026
Не знаешь, какой трек твой?
5 направлений ИБ, реальные зарплаты и точка входа для каждого — в одном треде.
JuniorSenior+
100K → 600K+ ₽ /мес
Открыть навигатор →
🔴 Свежие CVE, 0-day и инциденты
То, о чём ChatGPT ещё не знает — обсуждаем в реальном времени
Threat Intel →
💼 Вакансии и заказы в ИБ
Pentest, SOC, DevSecOps, bug bounty — работа и проекты от проверенных компаний
Карьера в ИБ →

HackerLab