OWASP ТОП-10 рисков безопасности API в 2023 году

Использование API продолжает стремительно расти. Как следствие, защита API должна быть более совершенной, чем когда-либо.

ТОП-10 наиболее актуальных рисков безопасности API в 2023 году

1. Некорректная авторизация на уровне объектов

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

Rapid7 рекомендует использовать этот механизм авторизации в каждой функции, которая получает клиентский ввод для доступа к объектам из хранилища данных. В качестве дополнительного средства усиления рекомендуется использовать криптографически защищенные случайные значения GUID для идентификаторов ссылок на объекты.

2. Некорректная аутентификация пользователей

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

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

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

3. Некорректная авторизация на уровне свойств объекта

Связанная с авторизацией на уровне объекта, авторизация на уровне свойств объекта - это еще один метод контроля для ограничения доступа к определенным свойствам или полям объекта. Эта категория сочетает в себе аспекты «чрезмерного раскрытия данных» и «массового присвоения», описанные в документе 2019 OWASP API Security. Если конечная точка API раскрывает чувствительные свойства объекта, которые не должны быть прочитаны или изменены неавторизованным пользователем, она считается уязвимой.

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

4. Неограниченное потребление ресурсов

Потребление ресурсов API относится к использованию центрального процессора, памяти, хранилища, сети и поставщика услуг для API. Атаки типа «отказ в обслуживании» возникают в результате чрезмерного потребления этих ресурсов, что приводит к простоям и увеличению стоимости услуг.

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

Также должны быть внедрены методы кодирования, которые ограничивают потребление ресурсов. Ограничьте количество записей, возвращаемых в ответах API, с осторожным использованием пейджинга, если это необходимо. Загружаемые файлы также должны иметь ограничения по размеру, чтобы предотвратить чрезмерное использование хранилища. Кроме того, необходимо тщательно оценивать производительность регулярных выражений и других средств обработки данных, чтобы избежать высокого потребления ЦП и памяти.

5. Некорректная авторизация на уровне функций

Отсутствие проверок авторизации в контроллерах или функциях за конечными точками API относится к нарушенной авторизации на уровне функций. Этот класс уязвимостей позволяет злоумышленникам получить доступ к несанкционированной функциональности; будь то изменение метода HTTP с `GET` на `PUT` для изменения данных, которые не должны быть изменены, или изменение строки URL с `user` на `admin`. Надлежащая проверка авторизации может быть затруднена из-за сложности контроллера и большого количества групп пользователей и ролей.

Комплексное моделирование угроз в отношении архитектуры и дизайна API имеет первостепенное значение для предотвращения этих уязвимостей. Убедитесь, что функциональность API тщательно структурирована, а соответствующие контроллеры выполняют проверку подлинности. Например, вся функциональность в конечной точке `/api/v1/admin` должна обрабатываться классом контроллера admin, который выполняет строгую проверку подлинности. Если есть сомнения, доступ должен быть запрещен по умолчанию, а разрешения должны выдаваться по мере необходимости.

6. Неограниченный доступ к конфиденциальным бизнес-потокам

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

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

7. Подделка запроса на стороне сервера

Уязвимости подделки запросов на стороне сервера (SSRF) возникают, когда клиент предоставляет URL или другой удаленный ресурс в качестве данных для API. В результате создается поддельный исходящий запрос на этот URL от имени API. Такие уязвимости часто встречаются в в параметрах URL-адреса перенаправления, веб-перехватчиках, функциях извлечения файлов и предварительном просмотре URL-адресов.

SSRF может быть использован злоумышленниками различными способами. Современное использование облачных провайдеров и контейнеров раскрывает URL метаданных экземпляра и внутренние консоли управления, которые могут быть использованы для утечки учетных данных и злоупотребления привилегированной функциональностью. Внутренние сетевые вызовы, такие как запросы бэкенд-сервисов к сервисам, даже если они защищены сервисными сетками и mTLS, могут быть использованы для получения неожиданных результатов. Внутренние репозитории, инструменты сборки и другие внутренние ресурсы могут быть объектом атак SSRF.

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

8. Ошибки настроек безопасности

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

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

9. Ненадлежащее управление активами

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

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

10. Небезопасное использование API

С данными, полученными от других API, нужно обращаться с осторожностью, чтобы предотвратить непредвиденное поведение. Сторонние API могут быть скомпрометированы и использованы для атак на другие API-сервисы. При работе с данными из других API следует учитывать такие атаки, как инъекция SQL, инъекция XML External Entity, атаки десериализации и другие.

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

Обращайтесь за персональной консультацией по решениям Rapid7 и с запросами на проведение пилотных проектов - к специалистам Softprom.

Softprom - Value Added Distributor компании Rapid7.