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

Категория OWASP: MASVS-PLATFORM: взаимодействие с платформой.

Обзор

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

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

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

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

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

Влияние

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

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

Злоумышленник также может использовать этот доступ для мошенничества, перенаправления сервисов и, в редких случаях, получения полного контроля над серверами.

Предотвращение атак

Stateful API

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

Кроме того, используйте безопасную аутентификацию, проверку клиентов и управление сеансами, предоставляемые сервисом API, и рассмотрите возможность использования динамического токена в качестве альтернативы статическому ключу. Убедитесь, что срок действия токена истекает через достаточно короткое время (обычно 1 час).

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

Реализуйте правильную обработку ошибок и ведение журнала:

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

Настройте OAuth в приложении:

  • Отправьте параметр redirect_uri конечным точкам авторизации и токена.
  • Если в вашем приложении используется OAuth со сторонним сервисом, настройте совместное использование перекрестных ресурсов (CORS), чтобы ограничить доступ к ресурсам приложения.
  • Используйте параметр state, чтобы предотвратить CSRF-атаки.

Используйте библиотеку безопасности:

  • Чтобы упростить реализацию безопасных процессов OAuth, используйте библиотеку безопасности, например AppAuth.
    • Эти библиотеки Android могут помочь автоматизировать многие из упомянутых ранее рекомендаций по безопасности.

Другие способы аутентификации, включая Firebase и токены идентификации Google, описаны в документации OpenAPI.

Stateless API

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

Для этого потребуется проксировать запросы между приложением и конечной точкой API. Один из способов сделать это – использовать веб-токены JSON (JWT) и веб-подпись JSON (JWS) или предоставить полностью аутентифицированный сервис, как рекомендовано выше. Это позволяет хранить уязвимый статический ключ на стороне сервера, а не в приложении (клиенте).

При создании сквозного решения без сохранения состояния в мобильных приложениях возникают определенные проблемы. Наиболее важные проблемы – это проверка клиента (приложения) и безопасное хранение закрытого ключа или секрета на устройстве.

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

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

Ресурсы