A08:2025 Нарушение целостности программного обеспечения или данных

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

Нарушение целостности программного обеспечения или данных сохраняет 8-е место с небольшим уточняющим изменением названия — с «Нарушения целостности программного обеспечения и данных». Категория сосредоточена на несоблюдении границ доверия и проверки целостности программного обеспечения, кода и артефактов данных на более низком уровне, чем уязвимости цепочки поставок. Категория фокусируется на допущениях, связанных с обновлениями программного обеспечения и критическими данными, без проверки их целостности. Среди значимых CWE: CWE-829: Включение функциональности из ненадёжной сферы управления, CWE-915: Неправильно контролируемое изменение динамически определяемых атрибутов объекта и CWE-502: Десериализация ненадёжных данных.

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

Число CWE	Макс. частота встречаемости	Ср. частота встречаемости	Макс. охват	Ср. охват	Ср. взвешенная эксплуатируемость	Ср. взвешенное воздействие	Общее число встречаемостей	Общее число CVE
14	8,98%	2,75%	78,52%	45,49%	7,11	4,79	501 327	3 331

Описание.

Сбои целостности программного обеспечения и данных связаны с кодом и инфраструктурой, не защищёнными от недопустимого или ненадёжного кода или данных, которые обрабатываются как надёжные и допустимые. Пример — когда приложение опирается на плагины, библиотеки или модули из ненадёжных источников, репозиториев и CDN. Небезопасный CI/CD-конвейер без проверок целостности программного обеспечения может привести к несанкционированному доступу, небезопасному или вредоносному коду или компрометации системы. Другой пример — CI/CD, получающий код или артефакты из ненадёжных мест и/или не проверяющий их перед использованием (проверкой подписи или аналогичным механизмом). Наконец, многие приложения содержат функцию автообновления, при которой обновления загружаются без достаточной проверки целостности. Злоумышленники могут загружать собственные обновления для распространения и запуска на всех установках. Ещё один пример — уязвимость к небезопасной десериализации, когда объекты или данные кодируются или сериализуются в структуру, которую злоумышленник может видеть и изменять.

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

Используйте цифровые подписи или аналогичные механизмы для проверки того, что программное обеспечение или данные получены из ожидаемого источника и не были изменены.
Убедитесь, что библиотеки и зависимости (например, npm или Maven) потребляются только из доверенных репозиториев. При повышенном профиле риска рассмотрите возможность размещения внутреннего проверенного репозитория.
Обеспечьте процесс проверки изменений кода и конфигурации для минимизации риска попадания вредоносного кода или конфигурации в конвейер разработки.
Обеспечьте надлежащее разделение, конфигурирование и контроль доступа в CI/CD-конвейере для обеспечения целостности кода в процессах сборки и развёртывания.
Убедитесь, что неподписанные или незашифрованные сериализованные данные не принимаются от ненадёжных клиентов и не используются без какой-либо формы проверки целостности или цифровой подписи для обнаружения подделки или воспроизведения.

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

Сценарий №1: Включение веб-функциональности из ненадёжного источника: Компания использует внешнего поставщика услуг поддержки. Для удобства создано DNS-сопоставление myCompany.SupportProvider.com на support.myCompany.com. Это означает, что все cookies, включая аутентификационные, установленные для домена myCompany.com, теперь отправляются поставщику поддержки. Любой, имеющий доступ к инфраструктуре поставщика поддержки, может похитить cookies всех пользователей, посетивших support.myCompany.com, и осуществить атаку с захватом сессии.

Сценарий №2: Обновление без подписи: Многие домашние маршрутизаторы, приставки, прошивки устройств и другие устройства не проверяют обновления с помощью подписанных прошивок. Неподписанная прошивка становится всё более привлекательной целью для злоумышленников. Это серьёзная проблема, поскольку зачастую нет механизма исправления, кроме как в будущей версии, а предыдущие версии постепенно выходят из употребления.

Сценарий №3: Использование пакета из ненадёжного источника: Разработчик с трудом находит обновлённую версию нужного пакета и скачивает его не из обычного доверенного менеджера пакетов, а с веб-сайта. Пакет не подписан, поэтому нет возможности обеспечить целостность. Пакет содержит вредоносный код.

Сценарий №4: Небезопасная десериализация: React-приложение обращается к набору микросервисов Spring Boot. Разработчики, приверженцы функционального программирования, пытаются обеспечить неизменяемость кода. Решение: сериализация состояния пользователя и передача его туда и обратно с каждым запросом. Злоумышленник замечает сигнатуру объекта Java «rO0» (в base64) и использует Java Deserialization Scanner для получения удалённого выполнения кода на сервере приложений.