Uso não seguro da API

Categoria do OWASP: MASVS-PLATFORM - Interação com plataformas

Visão geral

Muitos aplicativos para dispositivos móveis usam uma API externa para oferecer recursos. Tradicionalmente, um token ou uma chave estática é usada para autenticar o aplicativo que se conecta ao serviço.

No entanto, em um contexto de configuração cliente-servidor (ou app para dispositivos móveis e API), usar uma chave estática geralmente não é considerado um método de autenticação seguro para acessar dados ou serviços sensíveis. Ao contrário da infraestrutura interna, qualquer pessoa pode acessar uma API externa e abusar do serviço se tiver acesso a essa chave.

Por exemplo, é possível fazer engenharia reversa de uma chave estática do aplicativo ou interceptá-la quando um aplicativo móvel se comunica com a API externa. Também é mais provável que essa chave estática seja codificada no aplicativo.

O risco aos dados e serviços da API ocorre quando não são usados controles de acesso e autenticação suficientemente seguros.

Ao usar uma chave estática, a API pode ser explorada com a repetição de solicitações ou a criação de novas solicitações usando a chave (interceptada ou por engenharia reversa) sem restrições de tempo.

Impacto

Se um desenvolvedor estiver pagando por um serviço de API de IA ou ML, será relativamente fácil para um invasor roubar essa chave e acumular dívidas no serviço ou usá-la para criar conteúdo falso.

Todos os dados, arquivos ou informações de identificação pessoal (PII) armazenados na API ficariam disponíveis livremente, causando vazamentos prejudiciais.

Um invasor também pode usar esse acesso para cometer fraudes, redirecionar serviços e, em casos raros, assumir o controle total dos servidores.

Mitigações

API com estado

Se o aplicativo oferecer um login de usuário ou tiver a capacidade de rastrear sessões de usuários, recomendamos que os desenvolvedores usem um serviço de API como o Google Cloud para integração com estado no app.

Além disso, use autenticação segura, validação de cliente e controles de sessão fornecidos pelo serviço de API e considere usar um token dinâmico como uma alternativa a uma chave estática. Verifique se o token expira em um período razoavelmente curto (uma hora é o normal).

O token dinâmico deve ser usado para autenticação e fornecer acesso à API. Estas diretrizes mostram como fazer isso usando o OAuth 2.0. Além dessas diretrizes, o OAuth 2.0 pode ser ainda mais reforçado para reduzir vulnerabilidades no seu app Android implementando os seguintes recursos.

Implemente o tratamento de erros e o registro adequados:

  • Lide com os erros do OAuth de maneira adequada e visível, registrando-os para fins de depuração.
    • Uma superfície de ataque reduzida também ajuda a identificar e resolver problemas que possam surgir.
    • Verifique se as mensagens registradas ou apresentadas ao usuário são claras, mas não contêm informações úteis para um adversário.

Configure o OAuth com segurança no aplicativo:

  • Envie o parâmetro redirect_uri aos endpoints de autorização e token.
  • Se o app usar o OAuth com um serviço de terceiros, configure o Compartilhamento de recursos entre origens (CORS) para restringir o acesso aos recursos do app.
    • Isso ajuda a evitar ataques de scripting em vários locais (XSS) não autorizados.
  • Use o parâmetro "state" para evitar ataques CSRF.

Use uma biblioteca de segurança:

  • Considere usar uma biblioteca de segurança como o AppAuth para simplificar a implementação de fluxos OAuth seguros.
    • Essas bibliotecas do Android podem ajudar a automatizar muitas das práticas recomendadas de segurança mencionadas anteriormente.

Outros métodos de autenticação, incluindo tokens de ID do Firebase e do Google, são descritos na documentação do OpenAPI.

API sem estado

Se o serviço de API não oferecer nenhuma das proteções recomendadas anteriormente e houver uma exigência de sessões sem estado sem um login de usuário, os desenvolvedores talvez precisem fornecer as próprias soluções de middleware.

Isso envolveria o "proxy" de solicitações entre o app e o endpoint da API. Uma maneira de fazer isso é usar JSON Web Tokens (JWT) e JSON Web Signature (JWS) ou fornecer um serviço totalmente autenticado conforme recomendado anteriormente. Isso oferece uma maneira de armazenar a chave estática vulnerável no lado do servidor, em vez de no aplicativo (cliente).

Há problemas inerentes ao fornecer uma solução sem estado de ponta a ponta em aplicativos móveis. Alguns dos desafios mais importantes são a validação do cliente (app) e o armazenamento seguro da chave privada ou do segredo no dispositivo.

A API Play Integrity valida a integridade do aplicativo e das solicitações. Isso pode reduzir alguns dos cenários em que esse acesso pode ser usado de forma indevida. Quanto ao gerenciamento de chaves, em muitos casos, o keystore é o melhor local para armazenamento seguro de chaves privadas.

Alguns aplicativos móveis usam uma fase de registro para verificar a integridade do aplicativo e fornecer uma chave usando uma troca segura. Esses métodos são complexos e estão fora do escopo deste documento. No entanto, um serviço de gerenciamento de chaves na nuvem é uma possível solução.

Recursos