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

Категория OWASP: MASVS-ПЛАТФОРМА: Взаимодействие платформы

Обзор

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

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

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

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

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

Влияние

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

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

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

Смягчения

API с отслеживанием состояния

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

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

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

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

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

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

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

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

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

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

API без сохранения состояния

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

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

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

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

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

Ресурсы