A10:2025 Некорректная обработка исключительных ситуаций

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

Некорректная обработка исключительных ситуаций — новая категория 2025 года. Она содержит 24 CWE и охватывает ненадлежащую обработку ошибок, логические ошибки, небезопасные состояния сбоя и другие связанные сценарии, возникающие при нештатных условиях, с которыми могут столкнуться системы. В данной категории есть CWE, ранее связанные с низким качеством кода. Однако это было слишком общим; на наш взгляд, эта более конкретная категория обеспечивает лучшее руководство.

Среди значимых CWE в данной категории: CWE-209 Генерация сообщения об ошибке, содержащего конфиденциальную информацию, CWE-234 Сбой обработки отсутствующего параметра, CWE-274 Ненадлежащая обработка недостаточных привилегий, CWE-476 Разыменование нулевого указателя и CWE-636 Небезопасный сбой ('Failing Open').

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

Число CWE	Макс. частота встречаемости	Ср. частота встречаемости	Макс. охват	Ср. охват	Ср. взвешенная эксплуатируемость	Ср. взвешенное воздействие	Общее число встречаемостей	Общее число CVE
24	20,67%	2,95%	100,00%	37,95%	7,11	3,81	769 581	3 416

Описание.

Некорректная обработка исключительных ситуаций в программном обеспечении происходит, когда программы не предотвращают, не обнаруживают и не реагируют на нестандартные и непредсказуемые ситуации, что приводит к сбоям, непредвиденному поведению и иногда к уязвимостям. Это может включать один или несколько из трёх следующих сбоев: приложение не предотвращает возникновение нестандартной ситуации, не идентифицирует её в процессе возникновения и/или реагирует на неё неадекватно или вообще не реагирует.

Исключительные ситуации могут быть вызваны отсутствующей, неправильной или неполной проверкой входных данных, либо поздней высокоуровневой обработкой ошибок вместо их обработки в функциях, где они возникают, либо неожиданными состояниями среды — проблемами с памятью, привилегиями или сетью, непоследовательной обработкой исключений или необработанными исключениями, позволяющими системе перейти в неизвестное и непредсказуемое состояние. В любой момент, когда приложение неуверено в следующей инструкции, произошла некорректная обработка исключительной ситуации. Трудно обнаруживаемые ошибки и исключения могут долгое время угрожать безопасности всего приложения.

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

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

Для надлежащей обработки исключительной ситуации необходимо планировать заранее (ожидать худшего). Нужно «перехватывать» каждую возможную системную ошибку непосредственно в месте её возникновения и обрабатывать её (то есть предпринимать значимые действия для решения проблемы и восстановления). В рамках обработки следует включать генерацию ошибки (для информирования пользователя в понятном виде), журналирование события, а также оповещение, если это оправдано. Также необходимо иметь глобальный обработчик исключений на случай, если что-то было пропущено. В идеале следует также иметь инструменты или функциональность мониторинга и/или наблюдаемости, отслеживающие повторяющиеся ошибки или паттерны, указывающие на текущую атаку, и способные инициировать реагирование, защиту или блокировку. Это поможет блокировать и реагировать на скрипты и боты, направленные на уязвимости обработки ошибок.

Перехват и обработка исключительных ситуаций гарантирует, что базовая инфраструктура программ не остаётся один на один с непредсказуемыми ситуациями. Если транзакция любого рода выполняется частично, крайне важно откатить всю транзакцию и начать заново (также известно как безопасное закрытие — fail closed). Попытка восстановить транзакцию на полпути — это нередко источник невосстановимых ошибок.

По возможности везде добавляйте ограничение скорости, квоты на ресурсы, throttling и другие ограничения для предотвращения исключительных ситуаций в первую очередь. Ничто в информационных технологиях не должно быть безграничным, так как это ведёт к недостаточной устойчивости приложения, отказу в обслуживании, успешным атакам брутфорса и экстраординарным счетам в облаке. Рассмотрите, не следует ли идентичные повторяющиеся ошибки выше определённой частоты выводить только в виде статистики (частота и временной интервал). Эта информация должна добавляться к исходному сообщению, чтобы не мешать автоматизированному журналированию и мониторингу, см. A09:2025 Сбои журналирования и оповещения.

Помимо этого, необходима строгая проверка входных данных (с санацией или экранированием потенциально опасных символов), централизованная обработка ошибок, журналирование, мониторинг, оповещение и глобальный обработчик исключений. В одном приложении не должно быть нескольких функций для обработки исключительных ситуаций — это должно выполняться в одном месте, одинаковым образом каждый раз. Следует также создавать требования безопасности проекта для всех рекомендаций данного раздела, проводить моделирование угроз и/или обзор безопасного проектирования в фазе проектирования, выполнять ревью кода или статический анализ, а также нагрузочное, производительное и пенетрационное тестирование итоговой системы.

По возможности вся ваша организация должна обрабатывать исключительные ситуации одинаковым образом — это упрощает ревью и аудит кода для выявления ошибок в этом важном средстве контроля безопасности.

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

Сценарий №1: Исчерпание ресурсов вследствие некорректной обработки исключительных ситуаций (отказ в обслуживании) может произойти, если приложение перехватывает исключения при загрузке файлов, но не освобождает ресурсы после этого. Каждое новое исключение оставляет ресурсы заблокированными или иначе недоступными, пока все ресурсы не будут исчерпаны.

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

Сценарий №3: Повреждение состояния в финансовых транзакциях может быть вызвано злоумышленником, прерывающим многоэтапную транзакцию с помощью сетевых сбоев. Представьте, что порядок транзакции был: списать со счёта пользователя, зачислить на счёт назначения, записать транзакцию. Если система не выполняет откат всей транзакции (fail closed) при ошибке посередине, злоумышленник потенциально может опустошить счёт пользователя или создать состояние гонки, позволяющее многократно отправить деньги на счёт назначения.

Ссылки.

OWASP MASVS‑RESILIENCE