Skip to content

REST Assessment Cheat Sheet

О RESTful веб-сервисах

Веб-сервисы — это реализация веб-технологий, используемая для взаимодействия между машинами. Они применяются для взаимодействия между приложениями, в Web 2.0 и mashup-приложениях, а также настольными и мобильными приложениями для обращения к серверу.

RESTful веб-сервисы (часто называемые просто REST) — это облегчённый вариант веб-сервисов, основанный на паттерне проектирования RESTful. На практике RESTful веб-сервисы используют HTTP-запросы, схожие с обычными HTTP-вызовами, в отличие от других технологий веб-сервисов, например SOAP, которые используют сложный протокол.

Ключевые свойства RESTful веб-сервисов

  • Использование HTTP-методов (GET, POST, PUT и DELETE) в качестве основного глагола для запрашиваемой операции.
  • Нестандартные способы передачи параметров:
    • В составе URL.
    • В заголовках.
  • Структурированные параметры и ответы с использованием JSON или XML в значениях параметров, теле запроса или теле ответа. Это необходимо для передачи машиночитаемой информации.
  • Пользовательские механизмы аутентификации и управления сессиями, нередко с применением нестандартных токенов безопасности: это обусловлено тем, что при взаимодействии машин невозможно использовать обычные последовательности входа.
  • Отсутствие формальной документации. Предложенный стандарт описания RESTful веб-сервисов WADL был представлен компанией Sun Microsystems, однако так и не был официально принят.

Сложности при тестировании безопасности RESTful веб-сервисов

  • Анализ приложения не раскрывает поверхность атаки, то есть структуру URL и параметров, используемых RESTful веб-сервисом. Причины:
    • Ни одно приложение не использует все доступные функции и параметры, предоставляемые сервисом.
    • Используемые параметры зачастую активируются динамически клиентским кодом, а не в виде ссылок на страницах.
    • Клиентское приложение нередко не является веб-приложением и не позволяет изучить активирующие ссылки или даже соответствующий код.
  • Нестандартный характер параметров затрудняет определение того, что является частью URL или постоянным заголовком, а что — параметром, заслуживающим фаззинга.
  • Поскольку речь идёт о машинном интерфейсе, количество используемых параметров может быть очень большим: например, структура JSON может включать десятки параметров. Фаззинг каждого из них существенно увеличивает время, необходимое для тестирования.
  • Пользовательские механизмы аутентификации требуют обратной разработки и делают популярные инструменты непригодными, поскольку они не могут отслеживать сеанс входа.

Как проводить пентест RESTful веб-сервиса

Определите поверхность атаки через документацию — пентест RESTful может пройти успешнее, если допускается частичное тестирование типа «белый ящик» и вы можете получить информацию о сервисе.

Эта информация обеспечит более полное покрытие поверхности атаки. Искать следует:

  • Формальное описание сервиса — в то время как для других типов веб-сервисов, например SOAP, формальное описание (обычно в виде WSDL) зачастую доступно, для REST это редкость. Тем не менее как WSDL 2.0, так и WADL могут описывать REST и иногда применяются.
  • Руководство разработчика по использованию сервиса может быть менее детальным, но встречается значительно чаще и может даже рассматриваться как тестирование типа «серый ящик».
  • Исходный код или конфигурация приложения — во многих фреймворках, включая dotNet, определение REST-сервиса может быть легко получено из конфигурационных файлов, а не из кода.

Собирайте полные запросы с помощью прокси — это всегда важный шаг в пентесте, однако для приложений на базе REST он особенно важен, так как интерфейс приложения может не давать подсказок о реальной поверхности атаки.

Обратите внимание, что прокси должен уметь собирать полные запросы, а не только URL, поскольку REST-сервисы используют не только GET-параметры.

Анализируйте собранные запросы для определения поверхности атаки:

  • Ищите нестандартные параметры:
    • Обращайте внимание на нестандартные HTTP-заголовки — нередко это параметры, передаваемые через заголовки.
    • Определяйте, встречается ли повторяющийся паттерн в сегменте URL по всем URL-адресам. Такие паттерны могут включать дату, число или строку, похожую на идентификатор, и указывают на то, что данный сегмент URL является встроенным параметром.
      • Например: http://server/srv/2013-10-21/use.php
    • Ищите структурированные значения параметров — это могут быть JSON, XML или нестандартная структура.
    • Если последний элемент URL не имеет расширения, он может являться параметром. Особенно это вероятно, если технология приложения обычно использует расширения или если предыдущий сегмент имеет расширение.
      • Например: http://server/svc/Grid.asmx/GetRelatedListItems
    • Обращайте внимание на сильно варьирующиеся сегменты URL — отдельный сегмент URL с множеством различных значений может быть параметром, а не физической директорией.
      • Например, если URL http://server/src/XXXX/page повторяется с сотнями значений для XXXX, вероятно, XXXX является параметром.

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

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

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

Наконец, при выполнении фаззинга не забывайте эмулировать используемый механизм аутентификации.

Связанные ресурсы