Меню
Статьи

OWASP Top 10 2024: что изменилось

Что поменялось в списке OWASP: контроль доступа на первом месте, новые категории Insecure Design и SSRF, объединённые инъекции — и что с этим делать.

Главное изменение списка — Broken Access Control поднялся на первое место, а инъекции, которыми пугали десять лет, опустились ниже. Список собирают на данных реальных проектов, и он показывает не то, что страшнее звучит, а то, что чаще срабатывает.

Что поменялось

Было в 2021 Стало Что произошло
A05 Broken Access Control A01 Broken Access Control Поднялся на первое место
Отдельной категории не было A04 Insecure Design Ошибки проектирования выделены отдельно
Отдельной категории не было A10 SSRF Добавлена по данным о частоте
A03 Injection и A07 XSS A03 Injection Инъекции собраны в одну категорию

Контроль доступа — первое место

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

Сюда же относится доступность служебных интерфейсов снаружи. В июле 2023 года у сети салонов связи в интернете оказались данные 16 тысяч покупателей: файл создали через админ-панель сайта и получили несанкционированный доступ к базе, сообщал Office Life.

Что проверять: доступ между ролями отдельно от функциональных тестов, идентификаторы объектов в запросах, права на изменение и удаление, а не только на чтение, закрытость админ-панелей по адресам или через VPN.

Ошибки криптографии — второе

Категория переименована из Sensitive Data Exposure и стала шире: не только «данные утекли», но и «защищены не тем способом». Пароли без современной хеш-функции, база без шифрования, самоподписанные сертификаты во внутренних сервисах.

Руководитель кибербезопасности одного из белорусских операторов связи называет вторым по частоте сценарием незашифрованную клиентскую базу, подключённую напрямую к интернет-магазину на базовом движке.

Что проверять: TLS без устаревших версий, хеширование паролей через Argon2 или bcrypt, шифрование резервных копий, отсутствие ключей и паролей в репозитории.

Инъекции — третье, вместе с XSS

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

Что проверять: параметризованные запросы везде, включая динамические условия; экранирование при выводе; загрузку файлов и обработку XML.

Insecure Design — новая категория

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

Устаревшие компоненты

Библиотека сама по себе не уязвимость. Уязвимость — в том, что её годами не обновляют, а список того, что установлено, никто не ведёт.

Осенью 2024 года центр кибербезопасности хостинг-провайдера нашёл цепочку взломов сайтов на 1С-Битрикс с шаблонами «Аспро»: три уязвимых скрипта корзины, через них загружали веб-шеллы и майнеры. Один компонент, размноженный по десяткам клиентов.

В феврале 2025 года ОАЦ выявил критические уязвимости в сайтах, сделанных одним разработчиком больше двенадцати лет назад, и доступ к части из них был закрыт. Разработчик предупреждал владельцев об обновлении ещё в 2016 году.

Аутентификация и журналирование

Слабое место аутентификации — не пароли пользователей, а учётные записи с широким доступом: администраторы, сервисные записи, выгрузки. В апреле 2026 года у лизинговой компании утекла база на 241 тысячу строк, и причиной, по итогам внутреннего расследования, стало раскрытие учётных данных одного из работников — систему никто не взламывал.

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

Что делать

  1. Проверить права между ролями отдельно от функциональных тестов: не «работает ли», а «может ли пользователь получить чужое».
  2. Закрыть админ-панели и служебные интерфейсы от прямого доступа из интернета.
  3. Завести список компонентов с версиями и датой последнего обновления, включить проверку зависимостей в сборку.
  4. Включить второй фактор для всех учётных записей с доступом к базе целиком.
  5. Проверить, что журналы входов и изменений прав хранятся дольше месяца и их кто-то читает.

Как эти категории проверяют на практике — в статье методики пентестинга веб-приложений. Проверить приложение — безопасная разработка и ревью кода, hello@cyberiti.by.

Обсудить задачу и объём работ

Ответим в течение рабочего дня.