Skip to content

MASTG-TEST-0065: Teste de Criptografia de Dados na Rede

Visão Geral

Todos os casos apresentados devem ser analisados cuidadosamente como um todo. Por exemplo, mesmo que o aplicativo não permita tráfego em texto claro em seu Info.plist, ele ainda pode estar enviando tráfego HTTP. Isso pode acontecer se estiver usando uma API de baixo nível (para a qual o ATS é ignorado) ou um framework multiplataforma mal configurado.

IMPORTANTE: Você deve aplicar esses testes ao código principal do aplicativo, mas também a quaisquer extensões de aplicativo, frameworks ou aplicativos Watch incorporados no aplicativo.

Para mais informações, consulte o artigo "Preventing Insecure Network Connections" e "Fine-tune your App Transport Security settings" na Documentação para Desenvolvedores da Apple.

Análise Estática

Testando Solicitações de Rede por Meio de Protocolos Seguros

Primeiro, você deve identificar todas as solicitações de rede no código-fonte e garantir que nenhuma URL HTTP simples seja usada. Certifique-se de que informações sensíveis sejam enviadas por canais seguros usando URLSession (que utiliza o sistema padrão URL Loading System do iOS) ou Network (para comunicação em nível de socket usando TLS e acesso a TCP e UDP).

Verificando o Uso de APIs de Rede de Baixo Nível

Identifique as APIs de rede usadas pelo aplicativo e verifique se ele utiliza alguma API de rede de baixo nível.

Recomendação da Apple: Prefira Frameworks de Alto Nível em Seu Aplicativo: "O ATS não se aplica a chamadas que seu aplicativo faz para interfaces de rede de baixo nível, como o framework Network ou CFNetwork. Nesses casos, você assume a responsabilidade por garantir a segurança da conexão. É possível construir uma conexão segura dessa forma, mas erros são fáceis de cometer e custam caro. Geralmente é mais seguro confiar no URL Loading System" (veja fonte).

Se o aplicativo usar qualquer API de baixo nível, como Network ou CFNetwork, você deve investigar cuidadosamente se elas estão sendo usadas de forma segura. Para aplicativos que usam frameworks multiplataforma (por exemplo, Flutter, Xamarin, ...) e frameworks de terceiros (por exemplo, Alamofire), você deve analisar se eles estão sendo configurados e usados de forma segura, de acordo com suas melhores práticas.

Certifique-se de que o aplicativo:

  • verifica o tipo de desafio, o nome do host e as credenciais ao realizar a avaliação de confiança do servidor.
  • não ignora erros de TLS.
  • não usa configurações inseguras de TLS (consulte Testando as Configurações TLS)

Essas verificações são orientativas, não podemos citar APIs específicas, pois cada aplicativo pode usar um framework diferente. Use essas informações como referência ao inspecionar o código.

Testando Tráfego em Texto Claro

Certifique-se de que o aplicativo não está permitindo tráfego HTTP em texto claro. Desde o iOS 9.0, o tráfego HTTP em texto claro é bloqueado por padrão (devido ao App Transport Security (ATS)), mas há várias maneiras pelas quais um aplicativo ainda pode enviá-lo:

  • Configurando o ATS para habilitar tráfego em texto claro, definindo o atributo NSAllowsArbitraryLoads como true (ou YES) em NSAppTransportSecurity no Info.plist do aplicativo.
  • Recupere o Info.plist (consulte Explorando o Pacote do App)

  • Verifique se NSAllowsArbitraryLoads não está definido como true globalmente ou para qualquer domínio.

  • Se o aplicativo abrir sites de terceiros em WebViews, a partir do iOS 10, NSAllowsArbitraryLoadsInWebContent pode ser usado para desativar as restrições do ATS para o conteúdo carregado em visualizações da web.

A Apple adverte: Desativar o ATS significa que conexões HTTP não seguras são permitidas. Conexões HTTPS também são permitidas e ainda estão sujeitas à avaliação padrão de confiança do servidor. No entanto, verificações de segurança estendidas—como exigir uma versão mínima do protocolo Transport Layer Security (TLS)—são desativadas. Sem o ATS, você também tem liberdade para afrouxar os requisitos padrão de confiança do servidor, conforme descrito em "Performing Manual Server Trust Authentication".

O trecho a seguir mostra um exemplo vulnerável de um aplicativo desativando as restrições do ATS globalmente.

<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

O ATS deve ser examinado considerando o contexto do aplicativo. O aplicativo pode ter que definir exceções de ATS para cumprir sua finalidade. Por exemplo, o aplicativo Firefox iOS tem o ATS desativado globalmente. Essa exceção é aceitável porque, caso contrário, o aplicativo não conseguiria se conectar a nenhum site HTTP que não atendesse a todos os requisitos do ATS. Em alguns casos, os aplicativos podem desativar o ATS globalmente, mas habilitá-lo para determinados domínios para, por exemplo, carregar metadados com segurança ou ainda permitir login seguro.

O ATS deve incluir uma string de justificativa para isso (por exemplo, "O aplicativo deve se conectar a um servidor gerenciado por outra entidade que não suporta conexões seguras.").

Análise Dinâmica

Intercepte o tráfego de rede de entrada e saída do aplicativo testado e certifique-se de que esse tráfego esteja criptografado. Você pode interceptar o tráfego de rede de qualquer uma das seguintes formas:

  • Capture todo o tráfego HTTP(S) e Websocket com um proxy de interceptação como ZAP ou Burp Suite e certifique-se de que todas as solicitações sejam feitas via HTTPS em vez de HTTP.
  • Proxies de interceptação como Burp e ZAP mostrarão principalmente tráfego relacionado à web (por exemplo, HTTP(S), Web Sockets, gRPC, etc.). No entanto, você pode usar um plugin do Burp, como Burp-non-HTTP-Extension, ou a ferramenta mitm-relay para decodificar e visualizar a comunicação via XMPP e outros protocolos.

Alguns aplicativos podem não funcionar com proxies como Burp e ZAP devido ao Certificate Pinning. Nesse cenário, consulte Teste de Armazenamentos de Certificados Personalizados e Certificate Pinning.

Para mais detalhes, consulte: