Перейти к содержанию

API4:2019 Отсутствие Ограничений на Количество Запросов и Потребляемые Ресурсы

Источники угроз/Векторы атак Недостатки безопасности Последствия
Зависит от API : Сложность эксплуатации 2 Распространенность 3 : Сложность обнаружения 3 Технические последствия 2 : Зависит от бизнеса
Для эксплуатации необходимы простые запросы к API. Аутентификация не требуется. Злоумышленник может единовременно отправить большое количество запросов, используя локальный компьютер или облачную систему вычислений. Часто API не ограничивают количество запросов, или эти ограничения настроены некорректно. Эксплуатация может привести к отказу в обслуживании, выражающемся в долгом времени ответа или полной недоступности API.

Как определить, является ли API уязвимым?

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

  • Максимальное время ожидания выполнения
  • Максимальный объем выделяемой памяти
  • Количество файловых дескрипторов
  • Количество процессов
  • Размер полезной нагрузки запроса (например, размер загружаемого файла)
  • Количество запросов на одного клиента или ресурс
  • Количество записей из базы данных, возвращаемых в ответе на один запрос

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

Сценарий #1

Злоумышленник загружает большое изображение, отправив POST запрос на /api/v1/images. После завершения загрузки, API создает миниатюры изображения разного размера. Во время создания миниатюр приложение использует всю доступную память и перестает отвечать на запросы из-за большого размера загруженного изображения.

Сценарий #2

Рассмотрим приложение, отображающее список пользователей в пользовательском интерфейсе с ограничением 200 штук на страницу. Для получения списка пользователей приложение отправляет следующий запрос на сервер: /api/users?page=1&size=200. Злоумышленник увеличивает size до 200 000, что приводит к проблемам производительности в базе данных. API перестает отвечать на запросы и больше не может обработать запросы текущего или любого другого клиента (отказ в обслуживании).

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

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

  • Docker легко позволяет ограничить объем памяти, процессорное время, количество перезапусков, файловые дескрипторы и процессы.
  • Установите ограничение на частоту вызовов метода API одним клиентом в заданный промежуток времени.
  • Уведомите клиента, когда ограничение превышено, предоставив ему значение ограничения и время, когда ограничение будет сброшено.
  • Добавьте соответствующие проверки параметров строки запроса и тела запроса на стороне сервера, особенно важно контролировать количество записей, возвращаемых в запросе.
  • Определите и контролируйте максимальный размер данных, содержащихся во всех входных параметрах и полезных нагрузках, например, максимальную длину строки или максимальное количество элементов массива.

Ссылки

OWASP

Внешние