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

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

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

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

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

Что такое «отсутствие защиты от автоматизированных угроз»?

API страдает от уязвимости, называемой «Отсутствие защиты от автоматизированных угроз» (Unrestricted Access to Sensitive Business Flows, UASBF), если пользователь с недобрыми намерениями может использовать API системы для выполнения нежелательных действий в бизнес-процессах, реализованных системой, предоставляющей API. Цель такого пользователя — либо перегрузить или повредить систему, либо получить нежелательную или незаконную выгоду.

Например, рассмотрим ситуацию, когда в продажу поступает ограниченный тираж товара — это могут быть билеты на концерт, коллекционные предметы, билеты на спортивное событие и т.п.

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

Тестирование на нарушения UASBF

Рассмотрим как пример гипотетический магазин игр, который в основном продаёт обычные игры, скажем, Mario Kart. Заказ создаётся на сервере через HTTP POST запрос к эндпойнту /order с телом:

{
    "customerId": 12345,
    "articleId": 432,
    "articleDescription": "Mario Kart",
    "quantity": 1
}

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

{
    "customerId": 12345,
    "articleId": 432,
    "articleDescription": "Mario Kart",
    "quantity": 5
}

Однако иногда магазин получает ограниченный запас коллекционных товаров, и чтобы получить как можно больше довольных клиентов и уменьшить шансы перепродажи (скальпинга), устанавливается лимит — не более 1 копии на одного клиента:

{
    "customerId": 12345,
    "articleId": 987,
    "articleDescription": "Gamma Attack",
    "quantity": 1
}

Попытка заказать несколько копий Gamma Attack, как мы делали с Mario Kart в примере, приводит к сообщению об ошибке:

{
    "error": "Only 1 copy of Gamma Attack per person!"
}

Пока всё хорошо. Но возможно ли заказать несколько копий этого ограниченного издания, для которого действует правило «только 1 копия на человека», другими способами?

Оказывается, да! Хотя нельзя заказать несколько копий Gamma Attack в одном заказе, не существует ограничения на количество заказов Gamma Attack, которые может оформить один клиент. Это позволяет им перепродавать все копии, просто создавая множество заказов, каждый на одну копию, как только Gamma Attack поступает в продажу.

Как предотвратить нарушения UASBF?

Самое важное и эффективное, что вы можете сделать, чтобы защитить API от уязвимости UASBF — это выполнить четыре шага до того, как начнёте реализовывать и выпускать API:

1. Определите свои чувствительные бизнес-процессы и последствия злоупотребления ими — в нашем примере это процесс заказа ограниченных товаров в игровом магазине.
2. Определите способы, которыми злоумышленники могут злоупотреблять этими чувствительными бизнес-процессами — в примере это последовательные заказы нескольких копий Gamma Attack в короткий промежуток времени.
3. Внедрите меры противодействия, которые помогут предотвратить злоупотребления этими бизнес-процессами — подробнее об этом чуть позже.
4. Проведите тесты, чтобы убедиться, что риски, связанные с вашими чувствительными бизнес-процессами, были адекватно снижены.

В идеале шаги с 1 по 3 выполняются до начала реализации API и бизнес-логики. Я рекомендую обсуждать это с разработчиками, тестировщиками и продукт-менеджерами, чтобы минимизировать риск, что чувствительные бизнес-процессы и способы несанкционированного доступа к ним останутся незамеченными.

Снижение рисков нарушения UASBF

UASBF занимает 6-е место в рейтинге OWASP API Security Top 10 за 2023 год не случайно: когда злоумышленники регулярно могут злоупотреблять чувствительными бизнес-процессами, например, перепродавать ограниченные товары или загружать систему множеством заказов и бронирований, это серьёзно вредит имиджу вашего бизнеса и подрывает доверие пользователей к вашей честности и надежности.

Вот некоторые технические меры, которые помогут минимизировать риск уязвимости UASBF:

• Фингерпринтинг устройства — позволяет блокировать, например, headless-браузеры, которые часто используют злоумышленники.
• Обнаружение человека — с помощью капчи, либо более продвинутых (например, биометрических) решений, определяющих, выполняет ли действие человек или бот.
• Обнаружение неестественных шаблонов использования — например, если действия «добавить в корзину» и «оформить заказ» происходят за миллисекунды, скорее всего, это бот.

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

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

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

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