MASWE-0005: Chaves de API Hardcoded no Pacote do Aplicativo

Content in BETA

This content is in beta and still under active development, so it is subject to change any time (e.g. structure, IDs, content, URLs, etc.).

Send Feedback

Visão Geral

Chaves de API hardcoded no pacote do aplicativo, código-fonte ou binários compilados podem ser facilmente extraídas por meio de engenharia reversa.

Impacto

Hardcoding de chaves de API no aplicativo pode levar a uma variedade de problemas de segurança, incluindo, mas não se limitando a:

• Perda Financeira: Atacantes podem explorar as chaves de API comprometidas e hardcoded para fazer chamadas de API não autorizadas e abusar de serviços que são cobrados com base no uso (por exemplo, serviços de API de IA ou ML), resultando em cobranças inesperadas para o proprietário do aplicativo.
• Comprometimento da Integridade do Sistema e Operações de Negócio: Chaves de API extraídas podem dar aos atacantes acesso não autorizado a recursos e serviços sensíveis. Isso impacta diretamente desenvolvedores e empresas ao comprometer a integridade do aplicativo, a privacidade e a continuidade do serviço – potencialmente levando a interrupções como Negação de Serviço (DoS) ou suspensão de serviço devido a violações de políticas. Tais incidentes podem impactar significativamente a experiência do usuário, corroer a confiança do usuário e afetar negativamente a reputação e as operações do negócio.
• Contornar Mecanismos de Proteção: Chaves de API hardcoded podem facilitar o contorno de mecanismos de proteção do aplicativo. Atacantes podem usar isso para acessar conteúdo restrito, trapacear na funcionalidade do aplicativo ou desbloquear recursos destinados à compra, impactando tanto a receita quanto a experiência do usuário.

Modos de Introdução

Chaves de API podem ser hardcoded em várias áreas:

• Código-Fonte do Aplicativo: diretamente incorporadas no código-fonte do aplicativo.
• Ativos do Aplicativo: incluídas em arquivos destinados ao pacote final do aplicativo (normalmente APK/IPA), como arquivos de configuração, arquivos de manifesto e arquivos de recursos.
• Bibliotecas: arquivos de configuração ou código-fonte de bibliotecas de terceiros, próprias ou quaisquer outras dependências do aplicativo.

Mitigações

• Use um serviço de API com estado que forneça autenticação segura, validação do cliente e controles de sessão. Implemente tokens dinâmicos que expirem após um tempo razoavelmente curto (por exemplo, 1 hora). Isso pode ajudar a reduzir o impacto da exposição da chave. Além disso, garanta o tratamento adequado de erros e registro em log para detectar e responder a tentativas de acesso não autorizado. Considere usar OAuth 2.0 e bibliotecas de segurança como AppAuth para simplificar fluxos OAuth seguros.
• Se um serviço de API com estado não for viável, considere usar um serviço de API sem estado com uma solução de middleware (às vezes conhecida como proxy de API ou API Gateway). Isso envolve intermediar solicitações entre o aplicativo e o endpoint da API. Use JSON Web Tokens (JWT) e JSON Web Signature (JWS) para armazenar a chave estática vulnerável no lado do servidor em vez de no aplicativo (cliente). Implemente práticas seguras de gerenciamento de chaves e considere usar um serviço de gerenciamento de chaves em nuvem.
• Se as chaves de API precisarem ser hardcoded, certifique-se de configurá-las com as permissões mínimas necessárias para reduzir o impacto em caso de exposição. Muitos serviços permitem criar chaves com acesso restrito, o que limita as operações que podem ser realizadas.
• Considere usar um Serviço de Gerenciamento de Chaves para obter chaves de API em tempo de execução após validar a integridade do aplicativo.
• Faça auditorias regulares na base de código e nas dependências em busca de dados sensíveis hardcoded (por exemplo, usando ferramentas como gitLeaks).
• Use técnicas de criptografia de caixa branca para criptografar chaves de API e dados sensíveis dentro do aplicativo, garantindo que os algoritmos e chaves criptográficas permaneçam protegidos mesmo se o aplicativo for submetido à engenharia reversa.
• Embora não seja infalível, e a ser usado como último recurso quando nenhuma outra opção segura estiver disponível, a ofuscação e criptografia de código e recursos podem desencorajar atacantes ao dificultar a análise do seu aplicativo e a descoberta de segredos hardcoded. Evite implementações personalizadas e use soluções bem estabelecidas, como RASP (Runtime Application Self-Protection), que podem garantir que as chaves de API sejam montadas completamente na memória apenas quando necessário, mantendo-as ofuscadas ou divididas entre diferentes componentes caso contrário. O RASP também pode recuperar e gerenciar chaves dinamicamente com segurança em tempo de execução, integrando-se a soluções seguras de gerenciamento de chaves.