Comunicações em texto não criptografado

Categoria do OWASP: MASVS-NETWORK - Comunicação em rede (link em inglês)

Visão geral

Permitir comunicações de rede de texto não criptografado em um app Android significa que qualquer pessoa que monitora o tráfego de rede pode acessar e manipular os dados que estão sendo transmitidos. Isso se torna uma vulnerabilidade quando os dados transmitidos incluem informações sensíveis, como senhas, números de cartão de crédito ou outras informações pessoais.

Independente de você estar enviando informações sensíveis ou não, usar texto não criptografado ainda pode ser uma vulnerabilidade, já que o tráfego em texto não criptografado também pode ser manipulado por ataques de rede, como envenenamento de ARP ou DNS, permitindo que invasores influenciem o comportamento de um app.

Impacto

Quando um app Android envia ou recebe dados em texto não criptografado por uma rede, qualquer pessoa que esteja monitorando a rede pode interceptar e ler esses dados. Se esses dados incluem informações confidenciais, por exemplo, senhas, números de cartão de crédito ou mensagens pessoais, pode ocorrer roubo de identidade, fraude financeira e outros problemas graves.

Por exemplo, um app que transmite senhas em texto não criptografado pode expor essas credenciais a um usuário malicioso que esteja interceptando o tráfego. Esses dados podem ser usados para ter acesso não autorizado às contas do usuário.

Risco: canais de comunicação não criptografados

A transmissão de dados por canais de comunicação não criptografados expõe os dados compartilhados entre o dispositivo e os endpoints do aplicativo. Esses dados podem ser interceptados e modificados por um invasor.

Mitigações

Os dados precisam ser enviados por canais de comunicação criptografados. Protocolos seguros devem ser usados como alternativa a protocolos que não oferecem recursos de criptografia.

Riscos específicos

Esta seção reúne riscos que exigem estratégias de mitigação não padrão ou que foram mitigados em determinados níveis do SDK e estão aqui para referência.

Risco: HTTP

A orientação desta seção se aplica apenas aos apps destinados ao Android 8.1 (nível 27 da API) ou versões anteriores. A partir do Android 9 (nível 28 da API), clientes HTTP, como URLConnection, Cronet e OkHttp, exigem o uso de HTTPS. Por isso, o suporte a texto simples fica desativado por padrão. No entanto, outras bibliotecas de cliente HTTP, como Ktor (link em inglês), provavelmente não vão impor essas restrições em texto não criptografado e precisam ser usadas com cuidado.

Mitigações

Use o recurso NetworkSecurityConfig.xml para desativar o tráfego de texto não criptografado e aplicar o HTTPS no seu app, com exceções apenas para os domínios específicos necessários (geralmente para fins de depuração):

XML

<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
    <domain-config cleartextTrafficPermitted="true">
        <domain includeSubdomains="true">debug.domain.com</domain>
    </domain-config>
</network-security-config>

Essa opção ajuda a evitar regressões acidentais em apps devido a alterações nos URLs fornecidos por fontes externas, por exemplo, servidores de back-end.

Risco: FTP

Usar o protocolo FTP para trocar arquivos entre dispositivos apresenta vários riscos, sendo o mais significativo a falta de criptografia no canal de comunicação. Em vez disso, use alternativas mais seguras, como SFTP ou HTTPS.

Mitigações

Ao implementar mecanismos de troca de dados pela Internet no seu aplicativo, use um protocolo seguro, como HTTPS. O Android disponibiliza um conjunto de APIs que permitem aos desenvolvedores criar uma lógica cliente-servidor. Isso pode ser protegido usando o Transport Layer Security (TLS), garantindo que a troca de dados entre dois endpoints seja criptografada, evitando que usuários maliciosos espionem as comunicações e recuperem dados sensíveis.

Normalmente, as arquiteturas cliente-servidor dependem de APIs de propriedade do desenvolvedor. Se o aplicativo depender de um conjunto de endpoints de API, siga estas práticas recomendadas de segurança para proteger as comunicações HTTPS e garantir a segurança em profundidade:

  • Autenticação: os usuários precisam se autenticar usando mecanismos seguros, como o OAuth 2.0. A autenticação básica geralmente é desencorajada, já que não oferece mecanismos de gerenciamento de sessão e, se as credenciais forem armazenadas de maneira inadequada, elas poderão ser decodificadas do Base64.
  • Autorização: os usuários precisam ter acesso restrito apenas aos recursos pretendidos, seguindo o princípio de privilégio mínimo. Isso pode ser implementado com a adoção de soluções de controle de acesso cuidadosas para os recursos do aplicativo.
  • Verifique se os pacotes de criptografia mais recentes e adequados estão sendo usados, seguindo as práticas recomendadas de segurança. Por exemplo, considere oferecer suporte ao protocolo TLSv1.3 com compatibilidade com versões anteriores, se necessário, para comunicações HTTPS.

Risco: protocolos de comunicação personalizados

Implementar protocolos de comunicação personalizados ou tentar implementar manualmente protocolos conhecidos pode ser perigoso.

Embora os protocolos personalizados permitam que os desenvolvedores criem uma solução exclusiva que se adapta às necessidades pretendidas, qualquer erro durante o processo de desenvolvimento pode resultar em vulnerabilidades de segurança. Por exemplo, erros no desenvolvimento de mecanismos de processamento de sessões podem permitir que invasores interceptem comunicações e recuperem informações sensíveis em tempo real.

Por outro lado, implementar protocolos conhecidos, como HTTPS, sem usar bibliotecas de terceiros mantidas pelo SO ou por terceiros aumenta a probabilidade de introduzir erros de programação que podem dificultar, se não impossibilitar, a atualização do protocolo implementado quando necessário. Além disso, isso pode introduzir o mesmo tipo de vulnerabilidades de segurança que o uso de protocolos personalizados.

Mitigações

Use bibliotecas mantidas para implementar protocolos de comunicação conhecidos

Para implementar protocolos conhecidos, como HTTPS, no seu aplicativo, use bibliotecas do SO ou de terceiros mantidas.

Isso dá aos desenvolvedores a segurança de optar por soluções que foram testadas completamente, melhoradas ao longo do tempo e que recebem continuamente atualizações de segurança para corrigir vulnerabilidades comuns.

Além disso, ao optar por protocolos conhecidos, os desenvolvedores se beneficiam de uma ampla compatibilidade em vários sistemas, plataformas e IDEs, reduzindo a probabilidade de erros humanos durante o processo de desenvolvimento.

Usar o SFTP

Esse protocolo criptografa os dados em trânsito. Outras medidas precisam ser consideradas ao usar esse tipo de protocolo de troca de arquivos:

  • O SFTP é compatível com diferentes tipos de autenticação. Em vez da autenticação baseada em senha, use o método de autenticação de chave pública. Essas chaves precisam ser criadas e armazenadas com segurança. Para isso, recomendamos o Android Keystore.
  • Verifique se as cifras compatíveis seguem as práticas recomendadas de segurança.

Recursos