Технология REST API (также называемая RESTful API или RESTful web API) получили в последнее время широкое распространение. REST API — это интерфейс прикладного программирования, который соответствует принципам проектирования архитектурного стиля передачи состояния представления (REpresentational State Transfer, REST). REST API предоставляют гибкий и легкий способ интеграции приложений и подключения компонентов в архитектурах микросервисов. Однако, приложения REST API могут содержать различные уязвимости, позволяющие злоумышленникам использовать эти ошибки в своих целях. Для выявления этих уязвимостей могут использоваться различные средства, об одном из которых – фаззинге мы и поговорим в этой статье. Но для начала давайте рассмотрим основы технологии REST API.  

Основы REST API

На самом базовом уровне API — механизм, который позволяет приложению или службе получать доступ к ресурсу в рамках другого приложения или службы. Так приложение, которое получает доступ к ресурсам, является клиентами, а приложение, которое содержит ресурс, являются сервером. Некоторые API, такие как SOAP или XML‑RPC, накладывают на разработчиков жесткие рамки. Но разработчики могут разрабатывать REST API, используя практически любой язык программирования, и поддерживать различные форматы данных. Единственное требование заключается в том, чтобы они соответствовали основным принципам проектирования REST. Приложения должны иметь единый интерфейс (запросы API к одному и тому же ресурсу должны выглядеть одинаково, независимо от того, откуда поступает запрос, REST API должен гарантировать, что один и тот же фрагмент данных, такой как имя или адрес электронной почты пользователя, относится только к одному единому идентификатору ресурса (URI)).

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

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

Как работают REST API

REST API обмениваются данными посредством HTTP-запросов например, для выполнения стандартных функций базы данных, таких как создание, чтение, обновление и удаление записей в ресурсе.

Так, REST API будет использовать запрос GET для извлечения записи, POST для создания новой записи, PUT для обновления, а DELETE для ее удаления. В вызовах API можно использовать все методы HTTP. Хорошо разработанный REST API похож на веб-сайт, работающий в веб-браузере со встроенной функцией HTTP.

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

API Security Top 10

Известный проект OWASP не обошел своим вниманием и безопасность REST API. Ниже приводится список Top 10 уязвимостей.

API1:2023 — Нарушена авторизация на уровне объекта

API-интерфейсы, как правило, предоставляют доступ к конечным точкам, которые обрабатывают идентификаторы объектов, что создает широкие возможности для атаки на проблемы контроля доступа на уровне объекта.

API2:2023 — Нарушена аутентификация

Механизмы аутентификации часто реализуются неправильно, что позволяет злоумышленникам скомпрометировать токены аутентификации или использовать недостатки реализации для временного или постоянного присвоения идентификационных данных других пользователей. Нарушение способности системы идентифицировать клиента/пользователя ставит под угрозу безопасность API в целом.

API3:2023 — Нарушена авторизация на уровне свойств объекта

Здесь речь идет об отсутствии или неправильной проверке авторизации на уровне свойств объекта. Это приводит к раскрытию информации или манипулированию ею неавторизованными сторонами.

API4: 2023 — Неограниченное потребление ресурсов

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

API5:2023 — Нарушена авторизация на функциональном уровне

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

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

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

API7:2023 — Подделка запроса на стороне сервера

Ошибки, связанные с подделкой запросов на стороне сервера (SSRF), могут возникать, когда API извлекает удаленный ресурс без проверки предоставленного пользователем URI. Это позволяет злоумышленнику заставить приложение отправить созданный запрос в неожиданное место назначения, даже если оно защищено брандмауэром или VPN.

API8:2023 — Неправильная настройка системы безопасности

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

API9:2023 — Неправильное управление запасами

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

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

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

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

FuzzAPI

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

На Хабре уже были публикации, посвященные фаззингу REST API с помощью RESTler, но в этой статье мы рассмотрим другой инструмент FuzzAPI.

Установить FuzzAPI можно несколькими способами, но проще всего воспользоваться уже готовым контейнером, например woutervanderlinde/fuzzapi_web.

Для того, чтобы запустить контейнер с FuzzAPI и веб интерфейсом на порту 3000, воспользуемся следующей командой:

docker run -d -p3000:3000 woutervanderlinde/fuzzapi_web

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

FuzzAPI принимает запрос к API в качестве входных данных и возвращает данные о возможных уязвимостях.

Так, для запуска сканирования с использованием метода GET необходимо указать следующие параметры:

GET /scan/results?id=1 HTTP/1.1

Host: адрес_узла

В результате мы получим ответ в формате JSON со следующей структурой:

["id", "class_type", "scan_id", "parameter", "description", "value", "created_at", "updated_at", "status"]

Например:

[[1, "Vulnerability", "1", "", "Information Disclosure of Server version", "Server: PWS/8.2.1.6.5", "2017-07-26 02:50:45.044551", "2017-07-26 02:50:45.044551", "INFORMATIVE"]]

При использовании метода POST нам необходимо указать, какие данные мы хотим передать в запросе:

POST /scan/start HTTP/1.1

Host: адрес_узла

Raw header:

user=username&pass=password&headers=headers&url=https://google.com&params=parameters

Ответом будет следующий JSON:

Started the scan! The scan ID is: <number>

Заключение

Сканер FuzzAPI является бесплатным инструментом, позволяющим проверить на наличие уязвимостей REST API приложения. Грамотное использование данного сканера может существенно увеличить защищенность приложения.

На этом все. А уязвимости OWASP Top 10 Web мой коллега Иван Понуровский разберет на бесплатном вебинаре. Регистрация доступна по ссылке.