SQL-инъекция — это возможность подмешать собственную команду в запрос приложения к базе данных. Если приложение имеет доступ к таблице клиентов, атакующий получает тот же доступ: выгрузка базы занимает минуты и выполняется автоматизированным инструментом. Для оператора персональных данных это прямая дорога к составам частей 12–14 статьи 13.11 КоАП — от 3 до 15 млн ₽ за инцидент.
Как из инъекции получается утечка
Уязвимость возникает там, где данные из адресной строки или формы попадают в SQL-запрос через склейку строк. Приложение ожидает, что в параметре придёт число или слово, а получает фрагмент, который меняет смысл запроса целиком.
Дальше сценарий разворачивается по накатанной: атакующий определяет структуру базы, находит таблицу с пользователями, выгружает её постранично. Никакой изобретательности на этом этапе не требуется — работу делает готовый инструмент, а роль человека сводится к выбору цели. Поэтому массовые утечки редко бывают «целевыми атаками»: чаще это сканирование всего подряд и сбор того, что открылось.
Инъекции регулярно находятся в свежих проектах — в местах, куда не дотянулся ORM: ручные отчёты и выгрузки, поиск с динамической сортировкой, фильтры каталога, интеграционные эндпоинты и админские инструменты, написанные «на скорую руку». Фреймворк защищает типовой путь, а утечка происходит на нетиповом.
Разновидности, которые важно различать
| Тип | Как проявляется | Чем опасен для данных |
|---|---|---|
| Ошибочная (error-based) | Приложение возвращает текст ошибки СУБД | Быстрая разведка структуры базы, самая простая эксплуатация |
| Объединяющая (UNION-based) | Ответ страницы содержит подмешанные данные из другой таблицы | Прямая выгрузка содержимого таблиц в интерфейс сайта |
| Слепая логическая (boolean-blind) | Страница отвечает по-разному на истинное и ложное условие | Данные извлекаются побитово; медленнее, но так же полно |
| Слепая временная (time-based) | Ответ приходит с управляемой задержкой | Работает даже когда страница внешне не меняется вообще |
Различать их важно по одной практической причине: простые сканеры уверенно находят первые два типа и почти слепы к слепым. Если проверка сайта ограничилась поиском текста ошибки СУБД в ответе, отсутствие находок не означает отсутствия уязвимости.
Почему WAF не закрывает вопрос
Межсетевой экран уровня приложения отсекает типовые нагрузки и заметно снижает шум. Но он анализирует форму запроса, а не смысл кода, поэтому обходится кодированием, разбиением на части, нестандартным синтаксисом конкретной СУБД или работой через параметр, который WAF не разбирает. Плюс он не помогает, если запрос приходит по внутреннему каналу или через интеграцию.
Практический смысл WAF — выиграть время и сбить массовое сканирование. Практический смысл исправления в коде — убрать саму возможность. Первое без второго превращается в состояние «мы защищены, пока никто не постарается».
Ответственность оператора
С точки зрения закона неважно, какой техникой воспользовался атакующий. Важен результат: персональные данные вышли из-под контроля оператора. Отсюда цепочка:
Отдельная линия — уголовная: статья 272.1 УК РФ о незаконных использовании, передаче, сборе и хранении компьютерной информации, содержащей персональные данные, действует с 11 декабря 2024 года и применяется к физическим лицам.
Как проверить свой сайт
Проверка на инъекции — это динамическое тестирование: во все входные точки отправляются проверочные запросы, и анализируется реакция приложения. Качество проверки определяется двумя вещами.
- Полнота обхода. Сканер должен добраться до параметров, а не остановиться на главной странице. Формы, фильтры, поиск, пагинация, эндпоинты за JavaScript-навигацией — всё это точки входа.
- Подтверждение находки. «Возможна SQL-инъекция» — это гипотеза. Полезный результат выглядит иначе: приложен запрос, показана разница в поведении (управляемая задержка, различие ответов на истинное и ложное условие, ошибка СУБД) и указано, что именно доступно через эту точку.
Отчёт из пятисот «потенциальных» находок бесполезен: разработчик перестаёт их читать после десятой. Смысл имеет разделение на подтверждённые (воспроизводимые) и требующие проверки. У нас подтверждение делает отдельный слой-оракул, а не языковая модель: SQL-инъекция считается подтверждённой, если воспроизводится сигнатура или управляемая задержка, XSS — если код реально исполнился в браузере.
Как исправляют
- Параметризованные запросы. Данные передаются отдельно от текста запроса — подмешать команду становится нечем. Это единственное системное решение.
- ORM вместо ручной склейки везде, где это возможно; ручной SQL — только осознанно и с параметрами.
- Минимальные права пользователя БД. Приложению редко нужны права на чтение всех таблиц и на изменение схемы. Урезание прав ограничивает ущерб, даже если инъекция найдётся.
- Проверка логов задним числом. Найденная сегодня инъекция могла эксплуатироваться месяцами. Если следы есть — это уже инцидент со сроком уведомления в 24 часа, а не просто уязвимость.
- Повторная проверка после исправления. Фикс, который не проверили, регулярно оказывается неполным: закрыли один параметр, забыли соседний.