A05:2025 Инъекции

Общие сведения.

Инъекции опустились на две позиции — с 3-го на 5-е место, сохранив своё положение относительно A04:2025-Криптографические сбои и A06:2025-Небезопасное проектирование. Инъекции — одна из наиболее тестируемых категорий: 100% приложений проверяются на тот или иной вид инъекций. Категория имеет наибольшее число CVE среди всех — 37 CWE. Инъекции включают Cross-site Scripting (высокая частота/низкое воздействие) с более чем 30 тыс. CVE и SQL-инъекции (низкая частота/высокое воздействие) с более чем 14 тыс. CVE. Огромное количество CVE для CWE-79 снижает средневзвешенное воздействие данной категории.

Таблица оценок.

Число CWE	Макс. частота встречаемости	Ср. частота встречаемости	Макс. охват	Ср. охват	Ср. взвешенная эксплуатируемость	Ср. взвешенное воздействие	Общее число встречаемостей	Общее число CVE
37	13,77%	3,08%	100,00%	42,93%	7,15	4,32	1 404 249	62 445

Описание.

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

Приложение уязвимо к атакам, когда:

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

К наиболее распространённым инъекциям относятся SQL, NoSQL, команды ОС, ORM, LDAP и Expression Language (EL) или OGNL. Обнаружение лучше всего достигается сочетанием ревью исходного кода и автоматизированного тестирования (включая фаззинг) всех параметров, заголовков, URL, cookies, JSON, SOAP и XML. Добавление инструментов SAST, DAST и IAST в CI/CD-конвейер также может помочь выявить уязвимости инъекций до выпуска в производство.

Смежный класс уязвимостей инъекций стал распространённым в LLM. Они отдельно рассматриваются в OWASP LLM Top 10, в частности LLM01:2025 Prompt Injection.

Как предотвратить.

Лучший способ предотвращения инъекций — разделение данных и команд/запросов:

Предпочтительный вариант — использовать безопасный API, полностью исключающий использование интерпретатора, предоставляющий параметризованный интерфейс или выполняющий переход на ORM. Примечание: Даже при использовании параметризации хранимые процедуры могут содержать SQL-инъекцию, если PL/SQL или T-SQL конкатенирует запросы и данные или выполняет враждебные данные с помощью EXECUTE IMMEDIATE или exec().

Если разделить данные и команды невозможно, можно снизить угрозы следующими методами.

Используйте позитивную проверку входных данных на стороне сервера. Это не является исчерпывающей защитой, так как многие приложения требуют специальных символов, например текстовые поля или API для мобильных приложений.
Для оставшихся динамических запросов экранируйте специальные символы, используя синтаксис экранирования, специфичный для данного интерпретатора. Примечание: Структуры SQL, такие как имена таблиц, столбцов и т.д., не могут быть экранированы, поэтому предоставленные пользователем имена структур опасны. Это распространённая проблема в программах для создания отчётов.

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

Примеры сценариев атак.

Сценарий №1: Приложение использует ненадёжные данные при формировании следующего уязвимого SQL-запроса:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Злоумышленник изменяет значение параметра 'id' в браузере: ' OR '1'='1. Например:

http://example.com/app/accountView?id=' OR '1'='1

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

Сценарий №2: Чрезмерное доверие приложения к фреймворкам может привести к уязвимым запросам. Например, Hibernate Query Language (HQL):

Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

Злоумышленник передаёт: ' OR custID IS NOT NULL OR custID='. Это обходит фильтр и возвращает все учётные записи. Хотя HQL имеет меньше опасных функций, чем обычный SQL, он всё равно допускает несанкционированный доступ к данным при конкатенации ввода.

Сценарий №3: Приложение передаёт пользовательский ввод напрямую в команду ОС:

String cmd = "nslookup " + request.getParameter("domain");
Runtime.getRuntime().exec(cmd);

Злоумышленник передаёт example.com; cat /etc/passwd для выполнения произвольных команд на сервере.