Привет, Хабр!

Это инженерный отдел по динамическому анализу Swordfish Security. В предыдущих статьях мы описывали плагин для OWASP ZAP, рассказывали, как сканировать приложения с помощью инструмента Burp Suite Pro и настроить автоматическую авторизацию в DAST-сканере. Сегодня мы обсудим, на что можно обратить внимание при проверках API веб-приложения на безопасность. Обозревать будем со стороны практики динамического анализа, а в отдельной статье поделимся соответствующими инструментами. Поехали!

Введение

В процессе проверки веб-приложения на безопасность есть этап, на котором собираются все возможные точки взаимодействия с ним. Помимо анализа фронтенда, стоит проверить, как настроена коммуникация через API. В разных продуктах этот интерфейс используется с различными целями:

для связи фронтенда с бэкендом
для взаимодействия между разными приложениями одной организации
для предоставления доступа к бэкенду сторонним ПО и т. д.

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

Проект OWASP (Open Web Application Security Project) периодически выпускает рейтинг 10 основных категорий уязвимостей в веб-приложениях. Первый список был опубликован в 2003 году, последняя на текущий момент версия — в 2021-м. Такой же отчет для API выпускают с 2019-го. Из описания проекта: «A foundational element of innovation in today’s app-driven world is the API». Советуем ознакомиться с версией этого года, если хотите держать руку на пульсе.

С чего начать тестирование безопасности API веб-приложений? Сбор информации

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

Использованный протокол и формат данных имеют особое значение для корректного составления фаззинг-проверок и API-запросов на получение критических данных. На что нужно обратить внимание:

Используется ли REST-подход
В каком формате передаются данные
Есть ли API с протоколами SOAP, GraphQL, gRPC

Еще важно собрать информацию об устаревшем или неиспользуемом API, который могли не отключить. Также стоит пообщаться с командой разработки, получить старые версии спецификаций. Самостоятельно можно перебрать различные версии API. Например, при URL-е /api/v1 нужно посмотреть, какие ответы выдает сервер на v0 , v2, v3 и последующие. Не лишним будет подобрать эндпоинты перебором с использованием словарей популярных ключевых слов для API, обращая внимание на все нестандартные ответы.

Проверка авторизации

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

Помимо проверки наличия учетной записи у пользователя со стороны сервера, нужно разобраться вот с чем:

Какая используется ролевая модель? Важно следить за тем, чтобы пользователь не получил избыточный доступ к объектам и функциям приложения
Не полагается ли приложение на то, что данные от сервера фильтруются на уровне интерфейса? Из-за этого в API-ответе могут выводиться лишние данные
Можно ли выйти за рамки своей роли? Такое может произойти, если изменить соответствующий параметр в запросе или выполнить незадокументированные варианты применения функций к объектам
Есть ли небезопасные прямые ссылки на объекты?

Тестирование API на атаки

Осуществляя приведенные выше проверки, можно заодно собрать список потенциальных мест для атаки и в дальнейшем протестировать API на различные векторы инъекций, таких как SQL, NoSQL, LDAP, XML или Stored XSS.

Отдельно хочется выделить SSRF (Server-Side Request Forgery): она появилась в списке популярных категорий уязвимостей OWASP для веб-приложений в 2021 году, а в текущем попала в отчет рисков для API. Уязвимость возникает, когда API обращается к ресурсу без проверки URL-адреса, предоставляемого пользователем. Таким образом злоумышленник может заставить приложение отправить запрос по неожиданному пути, включая запросы к localhost и другим машинам в локальной сети приложения. Также SSRF служит хорошей входной точкой для других атак.

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

Фаззинг

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

Перебор HTTP-методов

Также нестандартные ответы от сервера можно получить, перебирая запросы API по словарю HTTP-методов. В этом случае могут возникнуть как разнообразные ошибки с дополнительной информацией, так и отрабатывающие корректно запросы с HTTP-методами, которые изначально не предполагались для использования. Таким образом можно столкнуться с обходом проверок на роль пользователя. Еще один пример: метод TRACE, который полезен при отладке, но отдает лишние данные в рабочей среде по типу IP-адреса промежуточных узлов связи. Неиспользуемые в приложении методы рекомендуем отключать.

Приманки

Один из методов отслеживания злоумышленников — создание приманок. С этой целью можно добавить API-эндпоинт, который не эксплуатируется в приложении и выдает несуществующие данные. Затем нужно добавить мониторинг на вызов этого эндпоинта или на обращение к несуществующим объектам, на которые ссылается ответ приманки.

Заключение

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

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

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

Безопасность API веб-приложений