Всем привет! Сегодня мы будем говорить о новых рисках в OWASP API Security Top 10, что плохого они нам обещают и что со всем этим можно сделать.

В 2023 году некоммерческая организация OWASP обновила свой отчёт и выпустила новую версию 2023. По сравнению с 2023 годом, перечень рисков претерпел довольно сильные изменения, которые мы постарались представить в виде таблицы. Дополнительно, в таблице отмечено, какие из пунктов уже сейчас покрываются продуктами от «Вебмониторэкс», а какие будут закрыты в ближайшем будущем.

Рис.1 Изменения в перечне рисков от OWASP и их покрытие продуктами от «Вебмониторэкс»

Стоит обратить внимание на пункт API2-2023 «Недостатки аутентификации». Наше видение заключается в том, что он остался без изменений. Однако, необходимо заметить, что в профессиональном сообществе есть два взгляда на указанный риск. Одна группа исследователей не находит изменений относительно отчёта за 2019 год. Пример можно найти в данной статье Noname «Changes to the OWASP API Security Top Ten 2019 to 2023». Другая точка зрения заключается в том, что пункт был расширен за счёт упоминания микросервисов и валидации JWT токенов. Например, статья Akto «What's changed in OWASP API Security Top 10 2023 Release Candidate from 2019?». Мы предоставляем нашим уважаемым читателям возможность самим сделать окончательный вывод о данном риске.

На наш взгляд, наибольший интерес представляют новые позиции в перечне: API6:2023 - Неограниченный доступ к чувствительным бизнес-процессам, API7:2023 - Атака на сервер с подделкой запроса (Server Side Request Forgery, SSRF) и API10:2023 - Небезопасное использование API.

API6:2023 - Неограниченный доступ к чувствительным бизнес-процессам.

Рассмотрим возможный сценарий атаки. Пример нами взят из OWASP API Security Top 10 2023. Авиакомпания продает билеты онлайн с возможностью бесплатной отмены заказа. Злоумышленник бронирует 90% доступных мест на определенном рейсе. Затем, за несколько дней до вылета, он одновременно отменяет все бронирования. Это вынуждает авиакомпанию снизить цены на билеты для заполнения оставшихся мест на рейсе. Таким образом, атакующий смог манипулировать ценами на билеты за счёт эксплуатации уязвимости в системе управления доступом.

В результате атаки злоумышленник получает возможность купить билет по значительно сниженной цене за счет искусственного создания избытка мест на рейсе.

Для предотвращения или затруднения реализации данной угрозы рекомендуется предпринимать следующие действия.

Отказ в обслуживании неожиданных клиентских устройств, например, браузеров без интерфейса.
Использование captcha или аналогичных решений, таких как анализ паттернов набора текста, для обнаружения ботов.
Анализ потока запросов для выявления использования средств автоматизации.
Блокировка IP-адресов выходных узлов Tor и известных прокси-серверов помогает защититься от потенциально опасных соединений.
Ограничение доступа к интеграционным API.

Например, модуль «Защита API» от компании «Вебмониторэкс» позволяет реализовать полноценную позитивную модель для управления доступом API, при которой будет заблокированы все запросы за пределами вашей OpenAPI спецификации. А модуль «Структура API» обеспечивает наблюдаемость API и построение соответствующей swagger спецификации, которую можно выгрузить и использовать отдельно. Подробнее о возможностях модуля можно почитать в нашей документации.

API7:2023 - Атака на сервер с подделкой запроса (Server Side Request Forgery, SSRF)

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

После этого происходит обработка запроса внутренним сервером с дальнейшей попыткой получить содержимое указанного URL-адреса без должной проверки и фильтрации. А затем, внутренний сервер подключается к указанному в URL-адресе внутреннему ресурсу (http://internal-server/internal-resource).

В итоге, злоумышленник получает возможность использовать SSRF для взаимодействия с внутренними сервисами, открывая дверь для дополнительных атак.

Для минимизации данного риска рекомендуются следующие действия.

Фильтрация и валидация входных данных на уровне API Gateway. Может быть реализовано с использованием регулярных выражений или белых списков разрешенных доменов.
Настройка API Gateway для разрешения доступа только к доверенным доменам из белого списка.
Настройка в API Gateway временных ограничений для запросов к внешним ресурсам.
Отключение на API Gateway возможности обращения к внутренним ресурсам. Для подключения к внутренним ресурсам рекомендуется реализовать отдельный механизм с дополнительными слоями аутентификации и авторизации.
Логирование и мониторинг в API Gateway для отслеживания попыток атак SSRF. Это позволит оперативно реагировать на подозрительную активность.
Регулярные обновления ПО и обучение персонала.

Использование продуктов компании «Вебмониторэкс», в том числе «Защита API» позволяет организовать эффективную защиту от атак типа SSRF .

API10:2023 - Небезопасное использование API

Рассмотрим потенциальный сценарий для реализации атаки. Например, есть API использующий сторонний сервис для автодополнения адресов, предоставляемых пользователем. Когда конечный пользователь передает часть адреса через API, происходит обращение к стороннему сервису, а возвращенные данные затем сохраняются SQL базе данных. Данные, получаемые от стороннего API никак не проверяются и не фильтруются. Сторонний сервис позволяет кому угодно дополнять информацию об адресах.

Для атаки, злоумышленник добавляет в сторонний сервис несуществующий адрес, который заканчивается SQL инъекцией, например some address'; DROP TABLE user_data; -- . Затем, атакующий формируют запрос к атакуемому API с адресом, созданным на предыдущем шаге. В результате, API обращается к стороннему сервису и получает в ответ данные с SQLi, фильтрации данных нет, SQLi попадает в запрос к БД, ломает его и исполняется. В данном примере происходит удаление таблицы "user_data".

В результате атаки, злоумышленники смогли удалить данные и нарушить работу сервиса.

Следование рекомендациям, представленным ниже, позволит профилактировать подобные типы атак.

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

Продукт «Защита API» может значительно усилить защиту от небезопасного использования API. А модуль «Структура API» поможет выявить shadow API, zombie API и orphan API. Злоумышленник может идентифицировать стороннее API, которое используется целевым API и имеет уязвимости. К таким уязвимостям можно отнести shadow API, zombie API и orphan API. Что это такое и как с этим работать читайте в нашей статье: «Обзор продукта «Структура API» и новой функциональности сравнения Open API спецификаций».

В нашей статье мы рассмотрели изменения, произошедшие в OWASP API Security Top 10, рассмотрели новые риски, появившиеся в перечне и описали рекомендации по минимизации данных рисков.

Тему обеспечения безопасности API в современных условиях мы подробно раскроем на нашем вебинаре 17 апреля в 12:00 (мск), регистрация по ссылке.

А также напоминаем, что нас есть Telegram-канал, в котором мы рассказываем все об API Security, Web Security и публикуем актуальные анонсы изменений в продукте, еще немного об уязвимостях и технические изыскания команды «Вебмониторэкс».
Будем рады видеть вас среди подписчиков нашего канала!
Читайте наши обзоры, оставайтесь защищёнными и помните, API first ближе, чем вы думаете!

Новые угрозы в OWASP API Security Top 10