Armazenamento e comunicações inseguras

Duas das vulnerabilidades móveis mais comuns são o armazenamento inseguro de dados e a comunicação insegura. Elas aparecem no Top 10 Mobile da OWASP.

Ambas resultam de desenvolvedores que confiam demais no dispositivo e protegem mal os dados.

Os aplicativos mantêm dados em /data/data/<package>/:

• SharedPreferences: arquivos XML de chave e valor.
• Bancos de dados SQLite.
• Arquivos internos e externos.

Os testadores de intrusão inspecionam cada local em busca de segredos armazenados sem proteção.

Uma falha frequente é armazenar senhas, tokens ou PII em texto simples no SharedPreferences ou em um banco de dados.

Em um dispositivo com root, por meio de backup ou com o Objection, um invasor pode ler esses dados diretamente. Dados sensíveis devem ser criptografados ou mantidos em hardware seguro.

Os dados gravados no armazenamento externo (a área do cartão SD) podem ser lidos por qualquer pessoa em versões antigas do Android e são acessíveis a qualquer aplicativo com permissão de armazenamento.

Salvar arquivos sensíveis nesse local os expõe a outros aplicativos. Registros gravados no disco representam um vazamento relacionado.

As opções seguras incluem o Android Keystore (chaves armazenadas no hardware e nunca expostas ao aplicativo) e o EncryptedSharedPreferences.

O Keystore pode executar operações criptográficas sem revelar a chave, o que é muito mais seguro do que uma chave embutida no código.

Comunicação insegura significa que os dados trafegam sem proteção adequada. O pior caso é o HTTP em texto simples, em que qualquer pessoa na rede pode ler ou modificar o tráfego.

Todo tráfego sensível deve usar HTTPS/TLS.

Para inspecionar o tráfego, encaminhe o dispositivo por meio de um proxy de interceptação, como o Burp Suite. Você instala o certificado CA do Burp no dispositivo para que o HTTPS possa ser lido.

Isso revela pontos de extremidade de API, parâmetros e quaisquer dados sensíveis em trânsito.

Aplicativos bem desenvolvidos usam fixação de certificado para rejeitar qualquer certificado que não seja o próprio, impedindo um proxy básico.

Como você aprendeu, um bypass de fixação de SSL com Frida desativa esse mecanismo, permitindo que você continue interceptando e avaliando a segurança real da API.

Mesmo com HTTPS, as falhas incluem confiar em todos os certificados, aceitar certificados expirados ou desativar a verificação do nome do host, muitas vezes como uma adaptação para facilitar o desenvolvimento.

Isso permite que um invasor execute um ataque de intermediário apesar da presença do TLS.

Mais dois vazamentos:

• android:allowBackup="true" permite que qualquer pessoa com acesso ao dispositivo extraia os dados do aplicativo por meio de adb backup.
• A saída detalhada do logcat pode exibir tokens ou PII.

Ambos devem ser desativados ou ter os dados tratados com segurança em produção.

Dois vazamentos frequentemente ignorados: copiar dados sensíveis para a área de transferência (legível por outros aplicativos em versões antigas do Android) e a captura de tela do sistema feita quando um aplicativo vai para segundo plano.

Aplicativos bancários atenuam esse risco com o sinalizador de janela FLAG_SECURE, que bloqueia capturas de tela e a prévia do alternador de tarefas.

Recapitule o local mais seguro para manter chaves criptográficas no Android.

Agora você entende o armazenamento e as comunicações inseguros:

• Os aplicativos vazam segredos em texto simples no SharedPreferences, em bancos de dados, no armazenamento externo e nos registros.
• Armazene segredos no Android Keystore ou no EncryptedSharedPreferences.
• As comunicações inseguras vão do HTTP em texto simples à validação fraca de TLS; intercepte-as com o Burp.
• Neutralize a fixação de certificado com o Frida; desative allowBackup e trate os registros com segurança.

Você concluiu o curso de Testes de Intrusão em Aplicativos Móveis.