Do achado ao relatório: confirmar, classificar e registrar
Como transformar uma lista de coisas estranhas num relatório de pentest mobile acionável: confirmação, severidade, CVSS e o que fazer depois de registrar.
Série · Parte 11 de 11 Segurança Mobile
- 01 O mapa da segurança mobile: OWASP MASVS, MASWE e MASTG 6 min
- 02 Arquitetura do Android: do kernel ao app 10 min
- 03 Arquitetura do iOS: do boot ao Secure Enclave 7 min
- 04 Análise estática no Android – parte 1: abrindo o APK 6 min
- 05 Análise estática no Android – parte 2: segredos no binário 4 min
- 06 Análise estática no Android – parte 3: manifesto e superfície de ataque 5 min
- 07 Análise estática no Android – parte 4: TLS, pinning e armazenamento 5 min
- 08 Scanners automáticos: o que eles pegam e o que passa batido 4 min
- 09 Análise estática no iOS: binário, Info.plist e entitlements 5 min
- 10 Análise dinâmica: o app rodando sob instrumentação 5 min
- 11 Do achado ao relatório: confirmar, classificar e registrar 4 min
Neste artigo6 seções
Todo o trabalho descrito nos artigos anteriores desta série, decompilar, ler o manifesto, revisar código nativo, rodar scanners, instrumentar o app em execução, produz uma coisa só: uma lista de coisas estranhas. Esse último artigo cobre o passo que transforma essa lista em algo útil, um relatório capaz de orientar uma correção.
Primeiro: confirmar, não só suspeitar
Uma string suspeita, um padrão de scanner, um comportamento inesperado: nenhum desses é, sozinho, um achado. Ele vira achado quando confirmado, e a barra de confirmação muda de acordo com de onde ele veio:
| Origem | Confirmado quando |
|---|---|
| Análise estática | O valor aparece no binário e sua origem é localizada no código-fonte |
| Análise dinâmica | O comportamento é reproduzido mais de uma vez, com um passo a passo que outra pessoa consegue seguir e obter o mesmo resultado |
| Scanner automático | Alguém revisou manualmente a saída. Resultado de scanner sozinho, sem essa revisão, não é achado, como visto no artigo sobre scanners |
Esse passo evita o problema mais comum de relatórios de segurança malfeitos: uma lista extensa onde metade dos itens é ruído, o que faz quem recebe o relatório perder confiança no restante, inclusive nos achados reais.
Classificando a severidade
Depois de confirmado, um achado precisa de uma severidade, que comunica o quanto ele é urgente sem exigir que quem lê entenda os detalhes técnicos de cada um:
| Severidade | Quando usar | Exemplo |
|---|---|---|
| Crítica | Acesso à conta ou aos dados de outro usuário, sem que ele precise fazer nada | Uma falha de autorização (IDOR) numa operação sensível |
| Alta | Uma credencial ou chave que dá acesso a um backend ou a um serviço de terceiro | Um client secret de confiança embutido no binário |
| Média | Facilita um ataque ou expõe algo que deveria ficar interno | Endereço de um ambiente de homologação, dado de teste esquecido numa build de produção |
| Baixa | Falta de reforço (hardening), sem um caminho de exploração direto e imediato | Tráfego sem criptografia liberado para um domínio de teste, log verboso demais |
| Informativa | Boa prática ou observação, sem risco de segurança direto | Metadado de build, versão de uma dependência que não tem vulnerabilidade conhecida |
Para precisar essa classificação de forma mais objetiva, principalmente quando o relatório precisa ser comparado com outros ou alimentar um processo formal, o padrão de mercado é o CVSS (Common Vulnerability Scoring System), hoje na versão 3.1, mantido pelo FIRST. Ele produz uma nota de 0 a 10 a partir de um vetor com métricas (como complexidade do ataque, privilégio exigido, impacto na confidencialidade), que a calculadora oficial gera automaticamente a partir das respostas.
Estrutura de um achado
Um relatório de pentest mobile costuma organizar cada achado confirmado com a mesma estrutura, repetida item a item:
### <n>. <Título curto do problema>
- **Controle violado:** referência ao padrão de verificação usado (ex.: um grupo do OWASP MASVS)
- **Onde no app:** arquivo, classe ou tela onde o problema aparece
- **Origem no código:** caminho e linha, quando houver acesso ao código-fonte
- **Como reproduzir:** passo a passo objetivo
- **Impacto:** o que um atacante consegue fazer, numa frase
- **Correção:** o que precisa mudar
- **Status:** aberto, em correção ou corrigido (e em qual versão)O campo "onde no app" merece uma ressalva: quando o valor encontrado é, de fato, um segredo (uma chave, um token), ele nunca deveria aparecer completo no relatório. A prática recomendada é mascarar a maior parte do valor, mostrando só os primeiros caracteres (o suficiente para quem corrige confirmar que é o valor certo, sem reproduzir o segredo inteiro num documento que pode circular por e-mail, chat ou um sistema de tickets):
echo 'CLIENT_SECRET = "a1b2c3d4e5f6..."' | sed -E 's/= "(.{0,6})[^"]*"/= "\1…"/'O mesmo princípio já apareceu no artigo sobre segredos no binário, aplicado direto na saída do BuildConfig.
De volta ao padrão: os controles do MASVS
O primeiro artigo desta série descreveu os oito grupos de controle do OWASP MASVS. Fechar o relatório apontando cada achado para o grupo correspondente (MASVS-STORAGE, MASVS-NETWORK, MASVS-PLATFORM e assim por diante) tem uma vantagem prática: transforma uma lista solta de problemas num mapa de cobertura, que permite comparar duas execuções do mesmo app ao longo do tempo e enxergar se um grupo inteiro de controles está sistematicamente mais fraco que os outros.
Depois de registrado
Registrar o achado não encerra o processo. Três coisas costumam vir em seguida:
- Segredo exposto exige rotação, não só correção de código. Se um valor sensível já foi publicado num binário distribuído, trocar o código não invalida o valor antigo: ele continua funcionando até ser revogado na origem, e o binário antigo continua instalado no aparelho de quem já baixou aquela versão.
- Achados Alto e Crítico merecem rastreamento formal, geralmente um ticket próprio, apontando para o registro detalhado, para que a correção entre no fluxo normal de trabalho do time, em vez de depender de alguém lembrar manualmente.
- Reteste fecha o ciclo. Depois da correção, gerar um novo build e repetir especificamente os passos do achado (não o processo inteiro) confirma se ele realmente foi resolvido, e o status no relatório é atualizado para refletir isso.
Encerrando a série
Os onze artigos desta série percorreram o caminho de uma análise de segurança mobile completa: o que muda quando o alvo é um app, como a arquitetura do Android e do iOS sustentam (ou não) as garantias que um app depende, como abrir e ler um APK e um IPA, onde segredos costumam vazar, o que o manifesto e o código nativo revelam, o papel (e os limites) dos scanners automáticos, como a análise dinâmica confirma o que a estática só sugere, e como transformar tudo isso num relatório que alguém consegue agir em cima. O padrão que amarra o processo inteiro continua sendo o mesmo descrito no primeiro artigo: o OWASP MAS, em suas peças que se complementam, do que verificar a como testar.
