Базовое использование sqlmap: Автоматизация поиска

Программа sqlmap — это мощная утилита на Python, предназначенная для автоматического поиска и эксплуатации SQL-инъекций. Зная всего один URL-адрес вашего Go-приложения, злоумышленник с помощью этого инструмента может в считанные минуты получить список баз данных, структуру таблиц и даже полностью выгрузить содержимое конфиденциальных таблиц, таких как users.

Разработана командой Бернардо Дамеле и Мирослава Стампара в 2006 году, утилита стала де-факто стандартом для пентестеров и багхантеров. На GitHub проект имеет 30+ тысяч звёзд, активно поддерживается, регулярно обновляется новыми векторами атак для каждой свежей CVE в популярных СУБД. По состоянию на 2025 год sqlmap знает паттерны для 36 различных СУБД (MySQL, PostgreSQL, Oracle, MSSQL, SQLite, MariaDB, IBM DB2, SAP HANA, ClickHouse и далее) и поддерживает 6 техник эксплуатации: boolean-based blind, time-based blind, error-based, UNION query-based, stacked queries, out-of-band.

Аналогия из физического мира: представь универсальную отмычку, которая знает 36 типов замков (английских, цилиндровых, дисковых, кодовых) и за пару минут перебирает все известные методы открытия. Замок не обязан быть «суперсложным», достаточно одной точки слабости — изношенной пружины или нестандартного штифта — и отмычка её найдёт. Так же sqlmap: он не «гениально взламывает» вашу систему, он методично прогоняет известный каталог уязвимостей через каждый параметр запроса, и при наличии любого конкатенированного SQL находит его.

Для команды разработки знание sqlmap критично с двух сторон. Во-первых, тот же инструмент можно использовать в pre-production пайплайне для самопроверки: запустить sqlmap против staging-окружения и убедиться, что ни один endpoint не отвечает на тесты. Во-вторых, понимание того, как именно работает инструмент атакующего, помогает писать осмысленные тесты безопасности — не угадывать, а воспроизводить реальные техники. Разберем базовые команды, которые используются для первичной разведки и извлечения данных.

---

1. Механика: Первая команда атаки

Для начала работы атакующему достаточно выполнить простую команду: sqlmap -u "http://target.com/item?id=1"

Перед нами минимальный синтаксис: флаг -u указывает на целевой URL с подозрительным параметром. sqlmap подставляет вместо значения 1 десятки тестовых payload'ов и анализирует ответы сервера: HTTP-код, длину тела, время отклика, наличие SQL-ошибок в выводе. Если хотя бы один из тестов даёт аномальный ответ — например, payload 1 AND SLEEP(5) приводит к задержке в 5 секунд — инструмент фиксирует факт уязвимости.

Что произойдет в этот момент:

1. sqlmap поочередно проверит параметр id на десятки типов инъекций (UNION, Blind, Time-based и др.).
2. При обнаружении уязвимости инструмент предложит оптимальный метод эксплуатации.
3. Программа автоматически определит тип и версию СУБД (например, PostgreSQL 14).

Определение СУБД работает через техники fingerprinting: sqlmap отправляет специфичные для каждого диалекта payload'ы и смотрит, какой из них «принимается». Например, функция version() есть в PostgreSQL и MySQL, но @@version — только в MySQL и MSSQL. Системная таблица pg_user существует только в PostgreSQL, mysql.user — в MySQL. По комбинации успешных запросов sqlmap с точностью 95%+ определяет не только семейство, но и конкретную версию — это критично, потому что для разных версий применяются разные техники эксплуатации.

---

2. Разведка структуры: Таблицы и колонки

После подтверждения уязвимости начинается этап «потрошения» базы данных:

• --dbs: Получение списка всех доступных баз данных.
• --tables -D public: Просмотр всех таблиц в выбранной схеме.
• --columns -T users: Извлечение названий колонок в таблице пользователей.

Этап извлечения данных (Dump):

sqlmap -u "..." -T users --dump

Результат: Все данные из таблицы (логины, хэши паролей, персональная информация) будут сохранены локально на компьютере атакующего.

sqlmap автоматически кладёт результаты в структурированную папку ~/.local/share/sqlmap/output/<host>/dump/<db>/<table>.csv. Дальше атакующий запускает hashcat против выгруженных bcrypt/sha256-хэшей паролей и при наличии слабых паролей (что встречается в 30-40% реальных баз) восстанавливает plaintext. Эти credentials используются для credential stuffing атак против других сервисов жертвы (LinkedIn, корпоративная почта, банк-клиент) — так одна SQLi на маленьком сайте может привести к компрометации корпоративных учёток через переиспользование паролей. Именно этот механизм стоял за инцидентом Yahoo Voices 2012 года, когда 450 тысяч plaintext-паролей утекли через SQL-инъекцию в недокументированном API.

---

3. Основные команды sqlmap

Команда	Описание	Результат для атакующего
-u "URL"	Тестирование параметра	Подтверждение наличия SQLi
--current-user	Проверка прав доступа	Определение привилегий в СУБД
--dump-all	Полная выгрузка	Критическая утечка всех данных

---

4. Почему sqlmap опасен для Go-проектов

Скорость работы программы в тысячи раз превышает возможности человека. Пока вы анализируете логи, sqlmap может перебрать сотни колонок и найти в заброшенной таблице забытый секретный ключ. Go обеспечивает высокую производительность сервера, но это никак не защищает от логических ошибок в SQL-запросах, таких как использование fmt.Sprintf.

Отдельно нужно подчеркнуть характерное заблуждение: «у меня Go, тут нет ORM, всё просто, инъекции не страшны». На самом деле Go-разработчики попадают в ловушку SQLi чаще, чем питонисты с Django ORM или джависты со Spring Data, потому что стандартная библиотека database/sql даёт два метода: db.Query(query) без параметров и db.Query(query, args...) с параметрами. Первый принимает любую строку, что соблазнительно использовать для динамических запросов с переменными колонками или условиями. Если разработчик уступает соблазну и собирает запрос через fmt.Sprintf — sqlmap находит этот endpoint за минуту автоматического сканирования. Никакая «быстрая go-горутина» не спасает: проблема не в производительности, а в логике формирования SQL.

Типовая ошибка: middleware валидирует параметр через strconv.Atoi (проверяет, что это число), но в SQL-запрос он подставляется через fmt.Sprintf("SELECT * FROM logs WHERE user_id=%d", id). Разработчик думает: «id уже число, инъекция невозможна». Это верно для этого конкретного параметра, но если рядом есть фильтр sort=name или dir=asc, который тоже подставляется через fmt.Sprintf, sqlmap найдёт инъекцию там — и через UNION-based извлечёт всю базу, начав с того самого logs.user_id параметра, который «защищён».

---

sqlmap — это эффективный и безжалостный инструмент. При наличии хотя бы одной уязвимой точки входа он неизбежно найдет её и позволит злоумышленнику полностью скомпрометировать систему.

Защита от автоматического сканирования — это не «спрятать endpoint» или «поставить капчу», это закрыть саму уязвимость на уровне кода. Если каждый SQL-запрос построен на bind-параметрах через db.Query(query, args...), sqlmap пройдёт все 36 диалектов и 6 техник, ничего не найдёт, и в финальном отчёте напишет «target appears to be not injectable». Это и есть желаемый результат. С точки зрения экономики: один разработчик, потративший день на ревью всех запросов в проекте, экономит компании потенциальный штраф от регулятора в миллионы долларов и стоимость инцидент-респонса.

Соответствие стандартам: PCI-DSS 6.5.1 требует «addressing common coding vulnerabilities» включая инъекции, и аудиторы используют тот же sqlmap для проверки. Если в pre-prod sqlmap находит SQLi — система не получит compliance-сертификацию. SOC 2 Type II аналогично требует доказательств защиты от инъекций в Control CC6.1 (Logical Access Security).

Далее мы изучим более продвинутые приемы использования sqlmap, включая уровни агрессивности и методы обхода систем защиты (WAF).