A03:2021- Внедрение кода

Обзор

Внедрение кода опускается на третью позицию. 94 % приложений были протестированы на наличие той или иной формы инъекций с максимальным коэффициентом встречаемости 19 %, средним коэффициентом встречаемости 3 % и 274 тыс. инцидентов. Известные CWE: CWE-79: Межсайтовый скриптинг, CWE-89: Внедрение SQL и CWE-73: Внешний контроль имени файла или пути.

Описание

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

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

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

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

Предотвращение внедрения требует хранения данных отдельно от команд и запросов:

• Предпочтительным вариантом считается использование безопасного API, который полностью исключает использование интерпретатора, предоставляет параметризованный интерфейс или переходит на инструменты объектно-реляционного сопоставления (ORM).

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

• Используйте положительную или "белую" проверку ввода на стороне сервера. Это не полная защита, так как многим приложениям требуются специальные символы, такие как текстовые области или API для мобильных приложений.
• Для любых остаточных динамических запросов экранируйте специальные символы, используя специальный синтаксис экранирования для этого интерпретатора.

Примечание: Структуры SQL, имена таблиц, имена столбцов и т.д., не могут быть экранированы, и поэтому имена структур, предоставленные пользователем, опасны. Это распространенная проблема в программном обеспечении для написания отчетов.

• Используйте ОГРАНИЧЕНИЯ и другие элементы управления SQL в запросах, чтобы предотвратить массовую утечку записей в случае внедрения SQL.

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

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

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

Сценарий № 2: Аналогично, слепое доверие приложения к фреймворкам может привести к запросам, которые все еще уязвимы (например, язык запросов Hibernate (HQL)):

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

В обоих случаях злоумышленник изменяет значение параметра "id" в своем браузере, чтобы отправить: "или "1"=’1. Например:

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

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