Дальнейшие шаги

По своей природе OWASP Top 10 ограничен десятью наиболее значимыми рисками. Каждый выпуск OWASP Top 10 содержит риски «на грани», которые долго рассматривались для включения, но в итоге не попали в список. Другие риски оказались более распространёнными и значимыми.

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

X01:2025 Недостаточная устойчивость приложений

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

Это переименование категории «Отказ в обслуживании» из 2021 года. Переименование обусловлено тем, что прежнее название описывало симптом, а не первопричину. Данная категория охватывает CWE, описывающие уязвимости, связанные с проблемами устойчивости. Оценка данной категории была очень близка к A10:2025-Некорректная обработка исключительных ситуаций. Соответствующие CWE: CWE-400 Неконтролируемое потребление ресурсов, CWE-409 Ненадлежащая обработка сильно сжатых данных (усиление данных), CWE-674 Неконтролируемая рекурсия и CWE-835 Цикл с недостижимым условием выхода ('Бесконечный цикл').

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

Число CWE	Макс. частота встречаемости	Ср. частота встречаемости	Макс. охват	Ср. охват	Ср. взвешенная эксплуатируемость	Ср. взвешенное воздействие	Общее число встречаемостей	Общее число CVE
16	20,05%	4,55%	86,01%	41,47%	7,92	3,49	865 066	4 423

Описание.

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

Кроме того, X02:2025 Сбои управления памятью также могут привести к сбою приложения или всей системы.

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

Для предотвращения этого типа уязвимостей необходимо проектировать системы с учётом возможности сбоев и восстановления.

Добавляйте ограничения, квоты и функциональность аварийного переключения, уделяя особое внимание наиболее ресурсоёмким операциям.
Идентифицируйте ресурсоёмкие страницы и планируйте заранее: сокращайте поверхность атаки, не открывая доступ для неизвестных или ненадёжных пользователей к ненужным «гаджетам» и функциям, требующим большого количества ресурсов (ЦП, памяти).
Выполняйте строгую проверку входных данных с использованием списков разрешённых значений и ограничений размера, затем тщательно тестируйте.
Ограничивайте размеры ответов и никогда не отправляйте клиенту необработанные ответы (обрабатывайте на стороне сервера).
Устанавливайте безопасное/закрытое состояние по умолчанию (никогда открытое), отказывайте по умолчанию и выполняйте откат при ошибке.
Избегайте блокирующих синхронных вызовов в потоках запросов (используйте асинхронные/неблокирующие подходы, устанавливайте таймауты, ограничения конкурентности и т.д.).
Тщательно тестируйте функциональность обработки ошибок.
Реализуйте паттерны устойчивости: автоматические выключатели (circuit breakers), переборки (bulkheads), логику повторных попыток и корректную деградацию.
Проводите производительное и нагрузочное тестирование; добавьте хаос-инжиниринг, если готовы к такому риску.
Реализуйте и проектируйте избыточность там, где это разумно и доступно.
Реализуйте мониторинг, наблюдаемость и оповещение.
Фильтруйте недопустимые адреса отправителей в соответствии с RFC 2267.
Блокируйте известные ботнеты по отпечаткам, IP-адресам или динамически по поведению.
Доказательство работы (Proof-of-Work): инициируйте ресурсоёмкие операции на стороне злоумышленника, которые не оказывают большого влияния на обычных пользователей, но влияют на ботов, пытающихся отправлять огромное количество запросов. Усложняйте Proof-of-Work при повышении общей нагрузки на систему, особенно для менее доверенных систем или кажущихся ботами.
Ограничивайте время серверной сессии на основе бездействия и финального таймаута.
Ограничивайте хранилище информации, привязанной к сессии.

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

Сценарий №1: Злоумышленники намеренно потребляют ресурсы приложения для провокации сбоев в системе, что приводит к отказу в обслуживании. Это может быть исчерпание памяти, заполнение дискового пространства, насыщение ЦП или открытие бесконечных соединений.

Сценарий №2: Фаззинг входных данных, приводящий к сформированным ответам, нарушающим бизнес-логику приложения.

Сценарий №3: Злоумышленники атакуют зависимости приложения, выводя из строя API или другие внешние сервисы, и приложение не может продолжать работу.

Ссылки.

Список связанных CWE

X02:2025 Сбои управления памятью

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

Языки Java, C#, JavaScript/TypeScript (node.js), Go и «безопасный» Rust являются памятобезопасными. Проблемы управления памятью, как правило, возникают в непамятобезопасных языках, таких как C и C++. Эта категория получила наименьшую оценку в опросе сообщества и низкую оценку в данных, несмотря на третье место по числу связанных CVE. Мы считаем, что это обусловлено преобладанием веб-приложений над традиционными настольными. Уязвимости управления памятью нередко имеют наибольшие оценки CVSS.

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

Число CWE	Макс. частота встречаемости	Ср. частота встречаемости	Макс. охват	Ср. охват	Ср. взвешенная эксплуатируемость	Ср. взвешенное воздействие	Общее число встречаемостей	Общее число CVE
24	2,96%	1,13%	55,62%	28,45%	6,75	4,82	220 414	30 978

Описание.

Когда приложение вынуждено самостоятельно управлять памятью, очень легко допустить ошибки. Памятобезопасные языки используются всё чаще, однако по всему миру по-прежнему работает множество устаревших систем, создаются новые низкоуровневые системы, требующие непамятобезопасных языков, а веб-приложения взаимодействуют с мейнфреймами, устройствами IoT, прошивками и другими системами, которые могут быть вынуждены управлять собственной памятью. Типичные CWE: CWE-120 Копирование буфера без проверки размера входных данных ('Классическое переполнение буфера') и CWE-121 Переполнение стекового буфера.

Сбои управления памятью могут происходить при:

Недостаточном выделении памяти для переменной.
Отсутствии проверки входных данных, вызывающей переполнение кучи, стека или буфера.
Хранении значения данных, превышающего максимум для типа переменной.
Попытке использования невыделенной памяти или адресных пространств.
Ошибках «на один» (счёт с 1 вместо 0).
Попытке доступа к объекту после его освобождения.
Использовании неинициализированных переменных.
Утечках памяти или ином исчерпании доступной памяти до сбоя приложения.

Сбои управления памятью могут привести к сбою приложения или всей системы, см. также X01:2025 Недостаточная устойчивость приложений.

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

Лучший способ предотвращения сбоев управления памятью — использовать памятобезопасный язык. Примеры: Rust, Java, Go, C#, Python, Swift, Kotlin, JavaScript и т.д. При создании новых приложений постарайтесь убедить организацию в том, что кривая обучения оправдывает переход на памятобезопасный язык. При полном рефакторинге добивайтесь переписывания на памятобезопасном языке, когда это возможно и целесообразно.

Если использование памятобезопасного языка невозможно:

Включите следующие функции сервера, затрудняющие эксплуатацию ошибок управления памятью: рандомизация адресного пространства (ASLR), защита от выполнения данных (DEP) и защита от перезаписи обработчиков структурированных исключений (SEHOP).
Отслеживайте утечки памяти в приложении.
Очень тщательно проверяйте все входные данные системы и отклоняйте всё, что не соответствует ожиданиям.
Изучите используемый язык и составьте список небезопасных и более безопасных функций, затем поделитесь этим списком со всей командой. По возможности включите его в руководство по безопасному кодированию. Например, в C предпочтительнее strncpy() перед strcpy() и strncat() перед strcat().
Если язык или фреймворк предлагает библиотеки для безопасной работы с памятью — используйте их. Например: Safestringlib или SafeStr.
Используйте управляемые буферы и строки вместо сырых массивов и указателей везде, где это возможно.
Пройдите обучение безопасному кодированию с акцентом на проблемы памяти и/или выбранный язык.
Выполняйте ревью кода и/или статический анализ.
Используйте инструменты компилятора для управления памятью, такие как StackShield, StackGuard и Libsafe.
Проводите фаззинг всех входных данных системы.
При тестировании на проникновение сообщите тестировщику об обеспокоенности проблемами управления памятью и попросите уделить им особое внимание.
Исправляйте все ошибки компилятора и предупреждения. Не игнорируйте предупреждения, если программа компилируется.
Убедитесь, что базовая инфраструктура регулярно обновляется, сканируется и укрепляется.
Специально мониторируйте базовую инфраструктуру на предмет потенциальных уязвимостей памяти и других сбоев.
Рассмотрите использование канареек для защиты стека адресов от атак переполнения.

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

Сценарий №1: Переполнения буфера — наиболее известная уязвимость памяти: ситуация, когда злоумышленник передаёт в поле больше информации, чем оно может принять, что приводит к переполнению буфера для базовой переменной. При успешной атаке символы переполнения перезаписывают указатель стека, позволяя злоумышленнику вставить вредоносные инструкции в программу.

Сценарий №2: Use-After-Free (UAF) встречается достаточно часто, чтобы быть распространённой заявкой в программах bug bounty браузеров. Злоумышленник создаёт JavaScript-нагрузку, управляющую DOM-элементами. Через тщательную манипуляцию он заставляет браузер освободить память объекта, сохраняя при этом висячий указатель. До того как браузер осознаёт освобождение памяти, злоумышленник выделяет новый объект, занимающий то же пространство памяти. Когда браузер пытается использовать исходный указатель, он теперь указывает на данные под управлением злоумышленника. Если этот указатель указывал на таблицу виртуальных функций, злоумышленник может перенаправить выполнение кода на свою нагрузку.

Сценарий №3: Сетевой сервис, принимающий пользовательский ввод, не проверяет и не обеззараживает его, а затем передаёт напрямую в функцию журналирования. Ввод пользователя передаётся как syslog(user_input) вместо syslog("%s", user_input), не задавая формат. Злоумышленник отправляет вредоносные нагрузки со спецификаторами формата, такими как %x для чтения памяти стека или %n для записи по адресам памяти. Это уязвимость форматной строки (неконтролируемый формат строки).

Примечание: современные браузеры используют многоуровневую защиту, включая песочницу браузера, ASLR, DEP/NX, RELRO и PIE. Атака с использованием сбоя управления памятью на браузер — непростая задача.

Ссылки.

Список связанных CWE

X03:2025 Неуместное доверие к коду, сгенерированному ИИ («Вайб-кодинг»)

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

Сейчас весь мир говорит об ИИ и использует его — и разработчики программного обеспечения не исключение. Хотя на сегодняшний день нет CVE или CWE, связанных с кодом, сгенерированным ИИ, хорошо известно и задокументировано, что такой код нередко содержит больше уязвимостей, чем код, написанный людьми.

Описание.

Мы наблюдаем изменение практик разработки программного обеспечения: теперь это включает не только код, написанный с помощью ИИ, но и код, созданный и зафиксированный почти без участия человека (нередко называемый «вайб-кодингом»). Подобно тому как никогда не было хорошей идеей копировать фрагменты кода из блогов или сайтов без обдумывания, в данном случае проблема усугубляется. Хорошие и безопасные фрагменты кода всегда были редкостью и могут статистически игнорироваться ИИ из-за системных ограничений.

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

Мы настоятельно рекомендуем всем, кто пишет код, учитывать следующее при использовании ИИ:

Вы должны быть способны читать и полностью понимать весь код, который вы отправляете, даже если он написан ИИ или скопирован с онлайн-форума. Вы несёте ответственность за весь код, который вы коммитите.
Тщательно проверяйте весь код с помощью ИИ на уязвимости — в идеале своими глазами и с использованием инструментов безопасности, предназначенных для этой цели (например, статического анализа). Рассмотрите использование классических методик ревью кода, описанных в OWASP Cheat Sheet Series: Secure Code Review.
В идеале пишите собственный код, позволяйте ИИ предлагать улучшения, проверяйте код ИИ и позволяйте ИИ вносить исправления до тех пор, пока вы не будете удовлетворены результатом.
Рассмотрите использование RAG-сервера (Retrieval Augmented Generation) с собственными собранными и проверенными безопасными примерами кода и документацией, такой как руководства, стандарты или политики безопасного кодирования вашей организации, и настройте RAG-сервер на соблюдение политик или стандартов.
Рассмотрите приобретение инструментов, реализующих ограждения для конфиденциальности и безопасности при использовании выбранного ИИ.
Рассмотрите приобретение частного ИИ, в идеале с договорным соглашением (включая соглашение о конфиденциальности) о том, что ИИ не будет обучаться на данных, запросах, коде или любой другой конфиденциальной информации вашей организации.
Рассмотрите внедрение сервера Model Context Protocol (MCP) между IDE и ИИ и настройте его на принудительное использование выбранных инструментов безопасности.
Реализуйте политики и процессы как часть SDLC для информирования разработчиков (и всех сотрудников) о том, как они должны и не должны использовать ИИ в вашей организации.
Создайте список эффективных промптов, учитывающих лучшие практики безопасности ИТ. В идеале они должны также учитывать внутренние руководства по безопасному кодированию. Разработчики могут использовать эти промпты как отправную точку для своих программ.
ИИ, вероятно, станет частью каждой фазы жизненного цикла разработки системы — как с точки зрения эффективного, так и безопасного использования. Используйте его мудро.
На самом деле не рекомендуется использовать вайб-кодинг для сложных функций, бизнес-критичных программ или программ, используемых длительное время.
Внедряйте технические проверки и защиту против использования теневого ИИ.
Обучайте разработчиков своим политикам, а также безопасному использованию ИИ и лучшим практикам применения ИИ в разработке программного обеспечения.

Ссылки.

OWASP Cheat Sheet: Secure Code Review

Список связанных CWE

-нет-