API
API (Application Programming Interface) позволяют приложениям обмениваться данными и взаимодействовать. Тестирование API важно, поскольку уязвимости в API могут подорвать ключевые аспекты конфиденциальности, целостности и доступности веб-сайта.
Все динамические веб-сайты состоят из API, поэтому классические веб-уязвимости, такие как SQL-инъекция, можно отнести к тестированию API. В этой теме мы рассмотрим как тестировать API, которые не полностью используются фронтендом сайта, с упором на RESTful и JSON API. Мы также рассмотрим, как тестировать уязвимости, связанные с загрязнением параметров на стороне сервера, которые могут повлиять на внутренние API.
Чтобы показать пересечение тестирования API и общего веб-тестирования, мы создали сопоставление между нашими существующими темами и OWASP API Security Top 10 2023.
Разведка API
Для начала вам следует выявить конечные точки API. Это места, где API принимает запросы о конкретном ресурсе на своем сервере. Например, рассмотрим следующий GET-запрос:
Конечная точка API для этого запроса — /api/books. Это приводит к взаимодействию с API для получения списка книг из библиотеки. Другой конечной точкой API может быть, например, /api/books/mystery, которая вернет список детективов.
После того как вы определили конечные точки, нужно понять, как с ними взаимодействовать. Это позволит вам конструировать корректные HTTP-запросы для тестирования API. Например, следует собрать следующую информацию:
Входные данные, которые обрабатывает API, включая обязательные и необязательные параметры.
Типы запросов, которые принимает API, включая поддерживаемые методы HTTP и медиатипы.
Лимиты частоты запросов и механизмы аутентификации.
Документация API
API обычно документируются, чтобы разработчики знали, как их использовать и интегрировать.
Документация может быть как человекочитаемой, так и машиночитаемой. Человекочитаемая документация предназначена для того, чтобы разработчики понимали, как использовать API. Она может включать подробные объяснения, примеры и сценарии использования. Машиночитаемая документация предназначена для обработки программным обеспечением, чтобы автоматизировать задачи, такие как интеграция и проверка API. Она пишется в структурированных форматах, таких как JSON или XML.
Документация API часто доступна публично, особенно если API предназначен для использования внешними разработчиками. В таком случае всегда начинайте разведку с изучения документации.
Поиск документации API
Даже если документация API не доступна открыто, вы все равно можете получить к ней доступ, просматривая приложения, которые используют API.
Для этого вы можете использовать Burp Scanner, чтобы сканировать API. Также вы можете вручную просматривать приложения с помощью браузера Burp. Ищите конечные точки, которые могут указывать на документацию API, например:
/api/swagger/index.html/openapi.json
Если вы обнаружили конечную точку ресурса, обязательно изучите базовый путь. Например, если вы обнаружили конечную точку ресурса /api/swagger/v1/users/123, то следует изучить следующие пути:
/api/swagger/v1/api/swagger/api
Вы также можете использовать список распространенных путей, чтобы находить документацию с помощью Intruder.
Использование машиночитаемой документации
Вы можете использовать ряд автоматизированных инструментов для анализа любой найденной машиночитаемой документации API.
Вы можете использовать Burp Scanner для сканирования и аудита документации OpenAPI или любой другой документации в формате JSON или YAML. Также вы можете разобрать документацию OpenAPI с помощью расширения OpenAPI Parser.
Вы также можете использовать специализированный инструмент для тестирования задокументированных конечных точек, такой как Postman или SoapUI.
Идентификация конечных точек API
Много информации можно собрать, просто просматривая приложения, которые используют API. Делать это полезно даже при наличии документации API, поскольку иногда документация может быть неточной или устаревшей.
Вы можете использовать Burp Scanner для сканирования приложения, а затем вручную исследовать интересную атакуемую поверхность в браузере Burp.
При просмотре приложения ищите в структуре URL шаблоны, которые указывают на конечные точки API, например /api/. Обращайте внимание и на файлы JavaScript. Они могут содержать ссылки на конечные точки API, которые вы не вызывали напрямую через веб-браузер. Burp Scanner автоматически извлекает некоторые конечные точки во время сканирования, но для более глубокой выборки используйте расширение JS Link Finder. Вы также можете вручную просматривать файлы JavaScript в Burp.
Взаимодействие с конечными точками API
Как только вы определили конечные точки API, взаимодействуйте с ними с помощью Burp Repeater и Burp Intruder. Это позволит наблюдать поведение API и выявлять дополнительную атакуемую поверхность. Например, вы можете изучить, как API реагирует на изменение метода HTTP и медиатипа.
При взаимодействии с конечными точками API внимательно анализируйте сообщения об ошибках и другие ответы. Иногда они содержат информацию, которую можно использовать для построения корректного HTTP-запроса.
Определение поддерживаемых методов HTTP
Метод HTTP определяет действие, выполняемое над ресурсом. Например:
GET— извлекает данные из ресурса.PATCH— частично изменяет ресурс.OPTIONS— возвращает информацию о типах методов запроса, которые можно использовать для ресурса.
Конечная точка API может поддерживать разные методы HTTP. Поэтому важно тестировать все потенциальные методы при исследовании конечных точек API. Это может позволить выявить дополнительную функциональность конечной точки и открыть больше атакуемой поверхности.
Например, конечная точка /api/tasks может поддерживать следующие методы:
GET /api/tasks— возвращает список задач.POST /api/tasks— создает новую задачу.DELETE /api/tasks/1— удаляет задачу.
Вы можете использовать встроенный список HTTP verbs в Burp Intruder, чтобы автоматически перебирать различные методы.
Определение поддерживаемых типов содержимого
Конечные точки API часто ожидают данные в определенном формате. Поэтому они могут вести себя по-разному в зависимости от типа данных, предоставленных в запросе. Изменение типа содержимого может позволить:
Вызвать ошибки, раскрывающие полезную информацию.
Обойти некорректные механизмы защиты.
Воспользоваться различиями в логике обработки. Например, API может быть безопасным при обработке данных в формате JSON, но уязвимым к внедрению при работе с XML.
Чтобы изменить тип содержимого, модифицируйте заголовок Content-Type, а затем соответствующим образом переформатируйте тело запроса. Вы можете использовать расширение Content type converter, чтобы автоматически конвертировать данные в запросах между XML и JSON.
Поиск скрытых конечных точек с помощью Intruder
После обнаружения первых конечных точек, вы можете использовать Intruder, чтобы найти скрытые конечные точки. Например, рассмотрим сценарий, в котором вы выявили следующую конечную точку API для обновления информации о пользователе: PUT /api/user/update
Чтобы обнаружить скрытые конечные точки, вы можете использовать Burp Intruder для поиска других ресурсов с такой же структурой. Например, вместо /update в пути можно перебрать список других распространенных функций, таких как delete и add.
Для поиска скрытых конечных точек, используйте списки слов на основе распространенных соглашений именования API и терминов отрасли. Обязательно включайте и термины, релевантные целевому приложению, исходя из данных первоначальной разведки.
Поиск скрытых параметров
Во время разведки вы можете обнаружить документально не описанные параметры, которые поддерживает API. Можно попытаться использовать их для изменения поведения приложения. В Burp есть множество инструментов, которые помогут выявлять скрытые параметры:
Burp Intruder позволяет автоматически обнаруживать скрытые параметры, используя список распространенных имен параметров для замены существующих параметров или добавления новых. Обязательно включайте имена, релевантные приложению, исходя из вашей первоначальной разведки.
Расширение Param miner позволяет автоматически перебирать до 65 536 имен параметров на запрос. Param miner автоматически подбирает соответствующие приложению имена на основе информации из скоупа.
Инструмент Content discovery позволяет обнаруживать контент, не связанный с видимыми элементами, включая параметры.
Уязвимости массового присваивания
Массовое присваивание (также известное как auto-binding — автоматическая привязка) может неявно создавать скрытые параметры. Это происходит, когда программные фреймворки автоматически привязывают параметры запроса к полям внутреннего объекта. Поэтому массовое присваивание может привести к тому, что приложение будет поддерживать параметры, которые изначально не планировалось обрабатывать.
Идентификация скрытых параметров
Поскольку массовое присваивание создает параметры из полей объекта, часто можно выявить эти скрытые параметры, вручную исследуя объекты, возвращаемые API.
Например, рассмотрим запрос PATCH /api/users/, который позволяет пользователям обновлять имя пользователя и email и содержит следующий JSON:
Параллельный запрос GET /api/users/123 возвращает следующий JSON:
Это может указывать на то, что скрытые параметры id и isAdmin привязаны к внутреннему объекту пользователя вместе с параметрами обновления имени пользователя и email.
Тестирование уязвимостей массового присваивания
Чтобы проверить, можно ли изменить значение параметра isAdmin, добавьте его в запрос PATCH:
Кроме того, отправьте запрос PATCH с некорректным значением параметра isAdmin:
Если приложение ведет себя по-разному, это может означать, что некорректное значение влияет на логику запроса, тогда как корректное — нет. Это может указывать на то, что параметр может быть успешно изменен пользователем.
Затем вы можете отправить запрос PATCH со значением параметра isAdmin, установленным в true, чтобы попытаться эксплуатировать уязвимость:
Если значение isAdmin в запросе привязывается к объекту пользователя без надлежащей валидации, пользователю wiener могут ошибочно выдать права администратора. Чтобы определить, так ли это, просмотрите приложение от имени wiener, чтобы проверить, можете ли вы получить доступ к функциональности администратора.
Предотвращение уязвимостей в API
При проектировании API убедитесь, что вопросы безопасности учитываются с самого начала. В частности, убедитесь, что вы:
Защищаете свою документацию, если не планируете публичный доступ к API.
Поддерживаете документацию в актуальном состоянии, чтобы у легитимных тестировщиков был полный обзор атакуемой поверхности API.
Применяете список разрешенных методов HTTP.
Проверяете, что тип содержимого соответствует ожидаемому для каждого запроса или ответа.
Используете обобщенные сообщения об ошибках, чтобы не раскрывать информацию, полезную для злоумышленника.
Применяете защитные меры ко всем версиям API, а не только к текущей продуктивной версии.
Чтобы предотвратить уязвимости массового присваивания, применяйте список разрешенных свойств, которые может обновлять пользователь, и список запрещенных для чувствительных свойств, которые пользователь обновлять не должен.
Last updated