Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой серии статей я обращусь к уязвимостям из списка топ-10 OWASP, посвященного безопасности API. В каждой статье я покажу вам, как экспериментировать с API, тестируя уязвимость, и обсужу свои выводы.

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

Вот весь список топ-10:

1. Некорректная авторизация на уровне объекта.
2. Некорректная аутентификация.
3. Авторизация на уровне свойств неработающего объекта.
4. Неограниченное потребление ресурсов (эта статья).
5. Ошибка авторизации на уровне функций.
6. Подделка запросов на стороне сервера.
7. Неправильная конфигурация безопасности.
8. Отсутствие защиты от автоматизированных угроз.
9. Неправильное управление запасами.
10. Небезопасное использование API.

Что такое неограниченное потребление ресурсов?

Говорят, что API страдает от неограниченного потребления ресурсов, если API или конкретный эндпойнт не ограничивают количество запросов клиента к нему или доступ к ресурсам, которые через него предоставляются.

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

Тестирование на уязвимости, связанные с неограниченным потреблением ресурсов

В качестве примера вспомним случай из предыдущей статьи этой серии, где мы тестировали некорректную авторизацию на уровне объекта. Там мы сканировали все номера счетов в диапазоне от 10000 до 20000, чтобы проверить, сможем ли получить доступ к данным, которые не должны быть нам доступны (спойлер: смогли).

Что сделало это возможным и, честно говоря, даже довольно простым, так это то, что API-эндпойнт позволял выполнять эти 10000 запросов подряд очень быстро — такую операцию легко выполнить с помощью скрипта или инструментов вроде Postman с кастомным источником данных.

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

Например, при превышении установленного лимита мы получили бы HTTP-ответ с кодом 429, сигнализирующий, что мы делаем слишком много запросов за короткий промежуток времени.

Снижение рисков неограниченного потребления ресурсов

Ограничение частоты запросов — одна из самых распространённых мер против уязвимостей, связанных с неограниченным потреблением ресурсов. Хотя этот метод, безусловно, эффективен, он не идеален:

• Во-первых, ограничение частоты — это своего рода ползунок: если установить слишком высокое значение, оно не будет эффективно; если слишком низкое — может негативно повлиять и на добросовестных пользователей ваших API. Поэтому требуется тщательное обдумывание и, скорее всего, экспериментирование, чтобы подобрать подходящие под ситуацию настройки.
• Во-вторых, в некоторых случаях уязвимость возникает не из-за количества запросов, а из-за характера отдельных вызовов. Например, если с помощью одного запроса можно выполнить массовую операцию (что довольно часто встречается в GraphQL-эндпойнтах), то даже один вызов API может причинить серьёзный вред.

Это верно и для многих мер безопасности API в целом: они помогают снизить вероятность уязвимостей, но сами по себе не гарантируют полную безопасность API.

Эта концепция имеет собственное название — “швейцарская модель безопасности”. Одна картинка стоит тысячи слов:

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

Дополнительные примеры

Больше примеров нарушений, связанных с неограниченным потреблением ресурсов, можно найти на странице OWASP API Security Top 10, посвящённой этой теме.

Курсы API Security Fundamentals и OWASP API Security Top 10 and Beyond на API Sec University содержат ещё больше примеров.

Обсудить в форуме