SQL-инъекции: как в 2026-м всё ещё воруют базы

SQL-инъекции известны больше двадцати лет. О них пишут в каждом учебнике, против них есть готовые инструменты в любом современном фреймворке. И всё же «инъекции» по-прежнему входят в OWASP Top 10 — список самых значимых рисков веб-приложений, где инъекциям посвящена отдельная категория (в редакции 2021 года — A03 Injection). Причина простая: уязвимость появляется не от незнания, а от спешки.

Механизм простыми словами

Сайт общается с базой данных на языке SQL. Когда клиент ищет свою заявку, приложение формирует запрос вроде «найди заявку с таким-то номером». Если номер берётся из адресной строки или формы и вклеивается в текст запроса как есть, у посетителя появляется возможность дописать в этот текст свои команды.

Представьте бланк, в котором клерк вписывает ваше имя в заранее подготовленное распоряжение. Если вместо имени написать «Иванов. А также выдать ему ключи от сейфа», а клерк перепишет это не глядя — распоряжение изменит смысл. База данных и есть такой исполнительный клерк: она выполняет то, что получила, и не отличает данные от команд.

Где инъекции прячутся в обменниках

В типичном обменном пункте опасные места почти всегда одни и те же.

Фильтры заявок. Оператору нужно искать заявки по дате, статусу, сумме, валюте. Чем больше фильтров, тем выше соблазн собрать условие запроса «склейкой строк».

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

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

«Быстрые доработки». Срочный отчёт для владельца, выгрузка для бухгалтерии, разовый скрипт сверки резервов. Такие вещи пишутся за вечер, мимо обычного ревью, и часто содержат «сырые» запросы.

Чем это грозит

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

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

Утечка KYC-данных — это не только репутационный удар. Это вопросы от регуляторов и банков-партнёров, а для клиентов — риск того, что их документы всплывут в мошеннических схемах.

Что защищает по-настоящему

Подготовленные выражения и ORM. Главная мера: данные передаются в базу отдельно от текста запроса. В Laravel это Eloquent и Query Builder с параметрами, в чистом PHP — PDO с плейсхолдерами. Когда данные и команды разделены, «дописать команду» становится невозможно.

Белые списки для сортировки и полей. Там, где параметр нельзя передать отдельно — имя колонки, направление сортировки, — приложение должно сверять значение со списком разрешённых. Пришло что-то не из списка — используем значение по умолчанию.

Минимальные права пользователя БД. Учётной записи сайта не нужны права на удаление таблиц или чтение системных таблиц. Отчётам, которые только читают, — отдельный пользователь только на чтение. Тогда даже успешная инъекция даст меньше, чем могла бы.

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

Ревью и статический анализ. Каждое изменение, которое касается запросов к базе, должен посмотреть второй человек. Инструменты статического анализа (SAST) умеют находить «склейку строк» в запросах автоматически — их стоит включить в CI, чтобы опасный код не доезжал до сервера.

Мониторинг аномальных запросов. Журнал ошибок базы данных — ценный источник сигналов. Всплеск синтаксических ошибок SQL от одного IP почти всегда означает, что кто-то подбирает инъекцию прямо сейчас.

Почему это всё ещё работает

Инъекции живут не в основном коде, который писали внимательно, а на окраинах: в старых модулях, разовых скриптах, «временных» отчётах, которые стали постоянными. Поэтому защита — это не одна библиотека, а дисциплина: единые правила работы с базой, ревью без исключений и регулярная проверка того, что уже написано.

SQL-инъекция — это ошибка процесса, а не нехватка знаний. Закрывается она тоже процессом.
Только подготовленные выражения или ORM — без исключений для «быстрых» скриптов.
Белые списки для имён полей и направлений сортировки.
Отдельные пользователи БД с минимальными правами для сайта, отчётов и админки.
Ревью и SAST в CI для всего, что касается запросов.
WAF и мониторинг ошибок SQL — как дополнительный слой, а не как основная защита.