O mapa da segurança mobile: OWASP MASVS, MASWE e MASTG

Quem desenvolve app mobile costuma pensar em segurança do lado do servidor: autenticação, rate limit, validação de entrada. O app é visto como uma "casca" que conversa com a API. O problema é que essa casca roda num aparelho que não é seu, na mão de alguém que pode abrir, modificar e observar tudo o que ela faz.

Rodar uma ferramenta de análise e receber um relatório, como no artigo O seu app React Native está seguro?, é só a superfície da segurança mobile. Por baixo existe uma área inteira, com padrão de verificação, catálogo de fraquezas e método de teste próprios.

Este artigo é um mapa dessa área: o que muda quando o alvo é um app, como o material de referência da OWASP se organiza e quais são os modos de teste.

O que muda quando o alvo é um app

Num teste de aplicação web, o código que importa está no servidor e você só vê o que ele devolve. No mobile é o contrário: o código inteiro do cliente está na mão do atacante.

Isso muda o modelo de ameaça:

• O APK pode ser baixado, descompactado e decompilado. Tudo o que foi embarcado nele (chaves de API, URLs internas, lógica de validação, flags de feature) pode ser lido.
• O aparelho pode estar com root, rodando num emulador ou com um framework de instrumentação injetado no processo do app. Nesse cenário o atacante muda o comportamento de qualquer função em tempo de execução.
• O tráfego pode ser interceptado colocando um proxy no meio, mesmo com HTTPS, se o app confiar no certificado errado.
• Os dados que o app grava no aparelho (banco local, preferências, cache, logs) podem ser lidos por quem tem acesso físico, por outro app com uma brecha ou por um backup.
• O app conversa com outros apps e com o sistema através de componentes expostos, deep links e WebViews. Cada uma dessas portas é uma superfície de ataque.

Então a pergunta deixa de ser só "minha API está protegida?" e passa a ser também "o que alguém consegue fazer com o meu app quando ele está num aparelho que essa pessoa controla?".

Pentest só com autorização

Antes de qualquer coisa: testar um app que não é seu, sem autorização por escrito, é crime em boa parte dos países, inclusive no Brasil. Para treinar existem apps vulneráveis de propósito, como os MAS Crackmes da OWASP.

O OWASP MAS

A principal referência da área é o OWASP Mobile Application Security, o projeto da OWASP dedicado a apps mobile. Ele não é um documento só, é um conjunto de peças que se encaixam:

O caminho entre elas é sempre o mesmo: um controle do MASVS se desdobra em várias fraquezas do MASWE, e cada fraqueza tem um ou mais testes no MASTG que dizem como encontrá-la.

MASVS: o que garantir

O MASVS divide a segurança de um app em oito grupos de controles:

Cada grupo tem fraquezas, ferramentas e técnicas próprias.

Perfis: nem todo app precisa de tudo

Um app de lista de compras e um app de banco não precisam do mesmo nível de proteção. Por isso a OWASP define perfis que dizem quais testes se aplicam:

• L1: o básico que todo app deveria cumprir.
• L2: defesa em profundidade, para apps que lidam com dados sensíveis (saúde, finanças, documentos).
• R: resiliência contra engenharia reversa e adulteração, para quando o próprio app é o ativo a proteger (jogos, DRM, apps que não podem ser clonados).
• P: privacidade, para avaliar como o app coleta e usa dados pessoais.

Um app bancário, por exemplo, geralmente é testado em L2 + R. Isso é importante porque evita o erro de tratar como vulnerabilidade algo que nem fazia parte do escopo, como reclamar da falta de detecção de root num app que não precisa disso.

MASTG: como testar

O MASTG é a parte mais prática. Ele é organizado em tipos de conteúdo, cada um com um identificador próprio:

A página de ferramentas separa tudo em genéricas, Android, iOS e rede. Algumas das mais citadas:

Estático, dinâmico e o tamanho da caixa

Os testes de app se dividem em dois grandes modos:

• Análise estática: olhar o app sem executar. Ler o AndroidManifest.xml, decompilar o bytecode, procurar segredos embarcados, ver quais componentes estão exportados. No caso de React Native, olhar o bundle JavaScript.
• Análise dinâmica: observar e manipular o app rodando. Interceptar tráfego, inspecionar o que ele grava em disco, chamar componentes expostos, usar Frida para trocar o retorno de uma função.

Uma não substitui a outra. A estática mostra o que pode acontecer; a dinâmica confirma o que acontece de fato. Na prática as duas se alternam: uma função suspeita encontrada na estática é confirmada, ou descartada, na dinâmica.

Também muda o quanto o testador sabe do alvo:

• Caixa preta: só o app publicado, como um atacante teria.
• Caixa cinza: o app mais alguma ajuda, como um build sem ofuscação ou credenciais de teste.
• Caixa branca: acesso ao código-fonte.

A caixa preta mostra o que um atacante enxerga; a caixa branca mostra por que aquilo acontece e onde está a origem no código.

Android e React Native

O MASTG cobre Android e iOS. O Android costuma ser a porta de entrada por três motivos:

• Acesso: dá para fazer quase tudo num emulador gratuito, com root, sem precisar de aparelho físico.
• Abertura: o sistema é open source. Quando surgir uma dúvida sobre como algo funciona por dentro, dá para ler o código do próprio Android.
• Material: a maior parte do conteúdo de pentest mobile, incluindo o HackTricks, é mais extensa para Android.

Apps React Native acrescentam uma camada a esse cenário. O código JavaScript vai dentro do APK como um bundle, normalmente compilado para o bytecode do Hermes, e conversa com o lado nativo através de módulos expostos pela ponte entre JS e Kotlin/Java. Isso muda onde ficam os segredos embarcados, como a lógica é decompilada e quais fraquezas aparecem só nesse tipo de app.

Além da OWASP

O guia de pentest Android do HackTricks é outra referência muito usada. Ele é menos formal que o MASTG e mais próximo de um caderno de campo: técnicas, comandos e truques organizados por tema, útil como checklist para conferir o que um teste cobriu e o que ficou de fora.