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.

Independentemente de você estar enviando informações sensíveis ou não, o uso de texto não criptografado ainda pode ser uma vulnerabilidade, já que o tráfego de texto não criptografado também pode ser manipulado por ataques de rede, como ARP ou envenenamento de DNS, permitindo que os 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 potencialmente modificados por um invasor.

Mitigações

Os dados precisam ser enviados por canais de comunicação criptografados. Os protocolos seguros devem ser usados como uma alternativa aos 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), os clientes HTTP, como URLConnection, Cronet e OkHttp, exigem o uso de HTTPS. Por isso, o suporte a texto não criptografado fica desativado por padrão. No entanto, é improvável que outras bibliotecas de cliente HTTP, como o Ktor, apliquem essas restrições em texto não criptografado e devem 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 ao 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

O uso do protocolo FTP para trocar arquivos entre dispositivos apresenta vários riscos, sendo o mais significativo a falta de criptografia no canal de comunicação. Use alternativas mais seguras, como SFTP ou HTTPS.

Mitigações

Ao implementar mecanismos de troca de dados pela Internet no aplicativo, use um protocolo seguro, como o HTTPS. O Android disponibiliza um conjunto de APIs que permitem que os desenvolvedores criem 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, impedindo que usuários mal-intencionados espionem as comunicações e recuperem dados sensíveis.

Normalmente, as arquiteturas cliente-servidor dependem de APIs pertencentes a desenvolvedores. Se o aplicativo depender de um conjunto de endpoints da API, garanta a segurança detalhada seguindo estas práticas recomendadas de segurança para proteger as comunicações HTTPS:

  • Autenticação: os usuários precisam se autenticar usando mecanismos seguros, como o OAuth 2.0. A autenticação básica geralmente não é recomendada, porque não oferece mecanismos de gerenciamento de sessão e, se as credenciais forem armazenadas incorretamente, poderão ser decodificadas a partir do Base64.
  • Autorização: os usuários precisam ser restritos para acessar apenas os recursos pretendidos, seguindo o princípio do menor privilégio. Isso pode ser implementado adotando soluções de controle de acesso cuidadoso para os recursos do aplicativo.
  • Confira se os pacotes de criptografia mais recentes e bem pensados são 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 protocolos conhecidos manualmente pode ser perigoso.

Embora os protocolos personalizados permitam que os desenvolvedores personalizem 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 fazer com que invasores consigam espionar comunicações e recuperar informações sensíveis em tempo real.

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

Mitigações

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

Para implementar protocolos conhecidos, como o HTTPS, no seu app, 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 atualizações de segurança contínuas para corrigir vulnerabilidades comuns.

Além disso, ao optar por protocolos conhecidos, os desenvolvedores se beneficiam de uma ampla compatibilidade entre vários sistemas, plataformas e ambientes de desenvolvimento integrados, 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 oferece suporte a diferentes tipos de autenticação. Em vez da autenticação com base em senha, o método de autenticação de chave pública deve ser usado. Essas chaves precisam ser criadas e armazenadas com segurança. Para essa finalidade, é recomendado o Android Keystore.
  • Verifique se as cifras compatíveis seguem as práticas recomendadas de segurança.

Recursos