Extraindo um Token de Sessão Salvo do Sandbox de um App Android

Todo app Android recebe um sandbox de armazenamento privado em /data/data/<package>. Dentro dele, a pasta shared_prefs guarda o SharedPreferences do app: configurações simples de chave/valor escritas como arquivos XML simples. Os apps usam esse armazenamento para tudo, de uma flag de modo escuro até, de forma menos sensata, um token de sessão logada. O diretório é privado no sentido de que outros apps não conseguem lê-lo, mas ainda assim são apenas arquivos em disco.

Essa distinção importa no momento em que alguém tem acesso a nível de arquivo. Um aparelho com root, um backup não criptografado, uma imagem forense ou, como aqui, um shell adb podem entrar em /data/data/com.example.acmebank/shared_prefs e abrir auth.xml. O app bancário salvou sua sessão ali como <string name="session">sess_4f91c2ad7e_prod</string>. Nada na leitura exige quebrar o app; o valor está em texto claro ao lado do nome de usuário.

Um token de sessão é uma credencial do tipo bearer: apresentá-la basta para agir como o usuário logado, sem precisar de senha. Por isso, um token recuperado do armazenamento local geralmente pode ser reaplicado diretamente contra a API do app para sequestrar a conta. É por isso que guardar uma sessão ativa em preferências de texto puro é tratado como uma vulnerabilidade real, não apenas cosmética: o limite do sandbox protege contra outros apps, não contra alguém com acesso ao sistema de arquivos do aparelho.

• Olhar primeiro na pasta databases. O token aqui está em shared_prefs/auth.xml, não no accounts.db do SQLite - as preferências são o lugar mais simples onde um app guarda uma sessão.
• Ler o sandbox do app errado. com.android.systemui é a interface do sistema, não o banco; o pacote alvo é com.example.acmebank.
• Abrir o settings.xml em vez do auth.xml. settings.xml guarda tema e idioma; a sessão de login fica em auth.xml.
• Supor que o token está criptografado. Ele é armazenado como uma string simples que o app lê de volta ao pé da letra, então basta ler o arquivo.

O armazenamento local do app não é um lugar seguro para uma credencial do tipo bearer. As correções mantêm o token fora de arquivos legíveis e limitam o dano caso o armazenamento seja exposto:

• Guardar tokens de sessão com o Android Keystore ou EncryptedSharedPreferences para que o valor em disco fique criptografado em repouso, não em XML simples.
• Manter os tokens de sessão de curta duração e vinculá-los ao aparelho, para que um token copiado expire rápido e não possa ser reaplicado em outro lugar.
• Excluir arquivos sensíveis dos backups (definir android:allowBackup="false" ou usar regras de backup) para que o token não seja exportado em um backup em texto claro.
• Detectar aparelhos com root ou adulterados e recusar persistir credenciais de longa duração neles.

Se um token de sessão foi exposto em disco, invalide essa sessão no lado do servidor e force uma nova autenticação: um token bearer vazado é utilizável até que o servidor pare de aceitá-lo.