Как анализировать .sql-файлы на наличие вредоносных запросов

К вам на руки попал .sql-файл. Может, это бэкап базы данных, который слал коллега. Может, вы скачали дамп из интернета. Или ваш разработчик передал файл для переноса на продакшен. Задача одна: убедиться, что внутри нет ничего, что навредит вашей базе данных. Разберёмся, как это сделать — без академической теории, на практике.

Почему .sql-файлы опасны

SQL-дамп — это не просто текст. Это набор команд, которые при выполнении создают таблицы, вставляют данные, меняют структуру базы. Если злоумышленник внедрил вредоносные конструкции, они сработают так же естественно, как и легитимные запросы.

Что могут скрывать в .sql-файле:

• Скрытые учётные записи администраторов в таблицах пользователей
• Редиректы на сторонние сайты, прописанные в данных полей
• Команды удаления или модификации критичных таблиц

li>Внедрение вредоносного кода в поля контента (XSS, iframe-инъекции)

• Команды операционной системы через xp_cmdshell или аналогичные расширения
• Дамп с подставными данными для фишинга

Главная проблема в том, что визуально отличить вредоносный запрос от обычного INSERT бывает очень сложно, особенно если файл большой.

Первичный осмотр: что проверить до запуска

Не спешите открывать файл в браузере или импортировать в базу. Начните с простых шагов, которые не требуют специальных инструментов.

1. Откуда файл? Если вы не знаете отправителя — это уже красный флаг. Даже от знакомых файлы стоит проверять.
2. Размер файла. Если дамп таблицы с тысячай строк весит 50 мегабайт — что-то не так. Возможно, внутри спрятан бинарный мусор или закодированный код.
3. Расширение и имя. Файл с именем backup_users.sql, который на самом деле содержит DROP DATABASE — классическая подстава.
4. Дата создания. Сверьте с тем, когда по логике должен был быть сделан бэкап.

Ручной анализ: на что смотреть в тексте

Откройте файл в текстовом редакторе с подсветкой синтаксиса — Notepad++, VS Code, Sublime Text. Не в Блокноте: в нём вы не увидите структуру и потеряете важные детали.

Строки, которые должны насторожить

Пройдитесь по файлу и поищите следующие конструкции:

• DROP TABLE, DROP DATABASE — удаление целых таблиц или баз. В обычном дампе такого быть не должно.
• TRUNCATE TABLE — очистка таблиц. Опасно, если не ожидаемо.
• CREATE USER, GRANT ALL PRIVILEGES — создание новых пользователей с полными правами.
• xp_cmdshell — запуск команд операционной системы из SQL Server. Почти никогда не нужен в дампе.
• INTO OUTFILE, INTO DUMPFILE — запись данных в файлы на сервере. Классический приём для размещения веб-шелла.
• LOAD_FILE() — чтение файлов с диска сервера.
• UNION SELECT в неожиданных местах — возможная попытка вытащить данные из других таблиц.
• Подозрительные URL в текстовых полях — особенно с <script>, <iframe>, javascript:.
• Base64-строки или длинные бинарные блоки в поле BLOB — могут содержать закодированный вредоносный код.

Пример скрытой инъекции

Вот как может выглядеть безобидная вставка данных с вредоносным дополнением:

INSERT INTO `users` (`id`, `username`, `email`, `role`) VALUES
(1, 'admin', 'admin@example.com', 'admin'),
(2, 'user', 'user@example.com', 'user'),
(3, 'backdoor', 'evil@mail.com', 'admin');
INSERT INTO `settings` (`key`, `value`) VALUES
('redirect_url', 'http://malicious-site.com');

На первый взгляд — обычный INSERT. Но третья строка создаёт скрытого администратора, а второй запрос прописывает редирект. Если не читать весь файл внимательно, это легко пропустить.

Автоматический анализ: инструменты

Ручной просмотр работает на малых файлах. Если дамп на сотни мегабайт — нужны инструменты.

grep и аналоги для быстрого поиска

Самый простой способ — поиск по ключевым словам. В Linux/macOS:

grep -iE "DROP |TRUNCATE |xp_cmdshell|INTO OUTFILE|LOAD_FILE|CREATE USER|GRANT ALL" dump.sql

В Windows можно использовать PowerShell:

Select-String -Path "dump.sql" -Pattern "DROP |TRUNCATE |xp_cmdshell|INTO OUTFILE" -CaseSensitive:$false

Это не заменяет полный анализ, но быстро находит явные подозрительные конструкции.

SQLMap

Инструмент для тестирования SQL-инъекций. Умеет анализировать дампы и находить уязвимые места. Запускается из командной строки:

sqlmap -r request_file --dump-all

Для анализа .sql-файла напрямую SQLMap не всегда удобен — он больше заточен под тестирование живых приложений. Но если вы знаете, что файл пришёл из подозрительного источника, можно загрузить его в тестовую базу и проверить через SQLMap уже работающее приложение.

Собственные скрипты

Если вы регулярно работаете с .sql-файлами, имеет смысл написать скрипт на Python или Bash, который парсит файл и проверяет его по списку опасных паттернов. Пример на Python:

import re

dangerous_patterns = [
    r'\bDROP\s+(TABLE|DATABASE)\b',
    r'\bTRUNCATE\s+TABLE\b',
    r'xp_cmdshell',
    r'INTO\s+(OUT|DUMP)FILE\b',
    r'LOAD_FILE\s*\(',
    r'CREATE\s+USER\b',
    r'GRANT\s+ALL\s+PRIVILEGES\b',
    r'<\s*script\b',
    r'<\s*iframe\b',
]

with open('dump.sql', 'r', encoding='utf-8') as f:
    content = f.read()

for pattern in dangerous_patterns:
    matches = re.findall(pattern, content, re.IGNORECASE)
    if matches:
        print(f"Найдено совпадение: {pattern} — {len(matches)} раз")

Это базовая проверка. В реальности список паттернов нужно расширять под ваш контекст.

Сравнение подходов к анализу

Как действовать в зависимости от ситуации

Ситуация 1: файл от знакомого разработчика

Попросите объяснить каждый непонятный запрос. Нормальный разработчик знает, что находится в его дампе. Если не может объяснить — это повод насторожиться. Загрузите файл в тестовую среду и проверьте результат.

Ситуация 2: файл скачан из интернета

Относитесь как к заведомо опасному. Не запускайте на продакшене. Проанализируйте всеми доступными методами. Если внутри чужой код — запускайте в изолированной среде (виртуальная машина, Docker-контейнер без доступа к сети).

Ситуация 3: файл найден на сервере и вы не знаете его происхождение

Это самый опасный случай. Файл мог быть оставлен злоумышленником после взлома. Не удаляйте его сразу — сначала проанализируйте, чтобы понять, что именно было сделано с вашей базой. Проверьте логи сервера на предмет несанкционированного доступа.

Ситуация 4: регулярный аудит безопасности

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

Частые ошибки при анализе

• Проверка только первых строк. Вредоносный код часто прячут в середине или в конце файла, среди тысяч легитимных INSERT-ов.
• Доверие к файлам из «проверенных» источников. Компрометация происходят и у надёжных поставщиков. Проверяйте всё.
• Игнорирование закомментированных блоков. Конструкции -- или /* ... */ могут скрывать подсказки или даже активный код, который выполнится при определённых условиях.
• Запуск файла напрямую на продакшене. Всегда сначала тестовая среда. Всегда.
• Проверка только SQL-синтаксиса. Вредоносный контент может быть спрятан прямо в данных — в текстовых полях, URL, HTML-фрагментах. Проверяйте не только структуру запросов, но и содержимое значений.
• Отсутствие контрольных сумм. Если вы загружаете файл из внешнего источника, сравните его хеш с заявленным. Несовпадение — признак подмены.

Практические рекомендации

1. Создайте чёрный список SQL-конструкций и используйте его для автоматической проверки всех входящих .sql-файлов. Обновляйте список по мере появления новых угроз.
2. Ведите журнал. Каждый .sql-файл, попадающий на сервер, должен быть задокументирован: откуда, когда, кто проверил, результат проверки.
3. Используйте изолированную среду для анализа. Docker-контейнер с MySQL/PostgreSQL, к которому нет доступа из сети — идеальное место для загрузки подозрительного дампа.
4. Проверяйте после загрузки. После импорта файла в тестовую базу проверьте: количество пользователей, наличие новых таблиц, изменения в правах доступа, содержимое ключевых полей контента.
5. Ограничьте права. Даже при загрузке дампа используйте учётную запись с минимально необходимыми привилегиями. Не используйте root-доступ без крайней необходимости.
6. Сверяйте структуру. Если у вас есть эталонная схема базы, сравните с ней результат загрузки. Любые расхождения — повод для расследования.

Что делать, если нашли подозрительное

Если в процессе анализа вы обнаружили что-то подозрительное:

• Остановите загрузку или выполнение файла
• Сохраните файл как уликоп (не изменяйте его)

Зафиксируйте найденные конструкции — скриншоты, строки, контекст

• Проверьте, не был ли файл уже выполнен на продакшене
• Если был — проведите аудит базы на предмет изменений, которых вы не запрашивали
• Сообщите ответственному за безопасность или руководителю

Итог

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

Главное правило: не доверяйте .sql-файлу только потому, что он привычного формата и якобы от знакомого человека. Проверяйте каждый раз. Время, потраченное на анализ, несопоставимо с потерями от взлома базы данных.