O pentest mobile baseado em OWASP MASVS e MASTG avalia a segurança de um aplicativo Android ou iOS contra um padrão público de verificação, em vez de uma lista pessoal do testador. A MASVS define os requisitos de segurança; o MASTG descreve como testá-los. O resultado é uma medição consistente e repetível da postura do aplicativo.
Um teste de invasão de aplicativo mobile mal estruturado costuma parar na superfície: o testador instala o app, clica em algumas telas, observa o tráfego e reporta o que apareceu. O problema não é a falta de esforço — é a falta de um referencial. Sem um padrão, dois testadores diferentes produzem dois relatórios incomparáveis sobre o mesmo aplicativo, e o cliente não tem como saber o que foi coberto e o que foi ignorado. O OWASP MASVS e o MASTG existem exatamente para fechar essa lacuna.
O que são MASVS e MASTG?
São dois artefatos complementares do OWASP Mobile Application Security Project.
- MASVS (Mobile Application Security Verification Standard) é o padrão de requisitos. Ele descreve, em linguagem de controle, o que um aplicativo mobile precisa fazer para ser considerado seguro — o "o quê". Serve como referência para definir escopo, contratar o teste e comparar resultados ao longo do tempo.
- MASTG (Mobile Application Security Testing Guide) é o guia de testes. Ele traduz cada requisito da MASVS em procedimentos concretos de análise estática e dinâmica — o "como". Traz técnicas específicas para Android e para iOS, com os pontos exatos a inspecionar.
A relação entre os dois é direta: a MASVS diz o que verificar, o MASTG diz como verificar. Juntos, transformam o pentest mobile de uma atividade artesanal em um processo auditável, no qual cada afirmação do relatório aponta para um requisito nomeado e um procedimento reproduzível.
A MASVS organiza os requisitos em categorias temáticas — armazenamento, criptografia, autenticação e gestão de sessão, comunicação em rede, interação com a plataforma, qualidade e proteção do código, resiliência contra engenharia reversa e privacidade. Cada categoria concentra um conjunto de controles, e o escopo do teste é definido escolhendo quais categorias se aplicam ao aplicativo e ao seu perfil de risco.
O que é testado em um pentest mobile MASVS?
O teste percorre as categorias da MASVS. Na prática, cada frente responde a uma pergunta específica sobre o aplicativo.
- Armazenamento de dados. O aplicativo grava dados sensíveis — tokens, credenciais, dados pessoais, chaves — de forma protegida? Avaliamos bancos SQLite, arquivos de preferências, cache, logs e o uso correto do Keychain (iOS) e do Keystore (Android). Dado sensível em texto claro no dispositivo é um dos achados mais frequentes.
- Criptografia. As primitivas e o gerenciamento de chaves seguem boas práticas? Procuramos algoritmos obsoletos, chaves embutidas no código, geração fraca de números aleatórios e uso incorreto de bibliotecas criptográficas.
- Autenticação e gestão de sessão. Como o app autentica o usuário e trata a sessão? Testamos o fluxo de login, o armazenamento e a expiração de tokens, a autenticação biométrica e a possibilidade de contornar controles locais.
- Comunicação em rede. O tráfego é protegido de ponta a ponta? Verificamos o uso de TLS, a validação de certificados e a presença — e a robustez — de certificate pinning contra ataques de interceptação.
- Interação com a plataforma. O app usa os recursos do sistema operacional de forma segura? Analisamos permissões, componentes exportados, deep links, WebViews, comunicação entre processos e o tratamento de dados vindos de outros aplicativos.
- Qualidade e proteção do código. O binário adota as proteções esperadas? Checamos configurações de build, ofuscação quando aplicável, tratamento de exceções e a exposição de informação de depuração.
- Resiliência contra engenharia reversa. Quando o modelo de ameaça exige, avaliamos detecção de root/jailbreak, anti-debug, anti-tampering e a resistência a instrumentação dinâmica. Essa categoria é opcional: nem todo aplicativo precisa dela, e ela nunca substitui os controles do lado do servidor.
- Privacidade. Quais dados o app coleta, para onde os envia e com que consentimento? Essa frente conecta o teste técnico às obrigações de proteção de dados.
Cada frente combina duas abordagens: a análise estática, que inspeciona o binário, o código descompilado e os arquivos de configuração sem executar o app; e a análise dinâmica, que observa o comportamento em tempo de execução — tráfego, chamadas de API, escrita em disco e reação a manipulação. O MASTG descreve as técnicas de ambas para cada plataforma.
Na prática, o engajamento segue uma sequência estável, mesmo quando a profundidade de cada etapa varia com o escopo contratado:
- Reconhecimento e mapeamento. Levantamos as telas, os fluxos, as permissões declaradas, os endpoints de back-end e as bibliotecas de terceiros que o aplicativo carrega.
- Preparação do ambiente. Configuramos o dispositivo ou emulador, os certificados de interceptação e as ferramentas de instrumentação necessárias à plataforma.
- Análise estática. Descompilamos o binário, inspecionamos configurações de build e procuramos segredos embutidos, criptografia fraca e componentes mal configurados.
- Análise dinâmica. Executamos o app sob observação, manipulamos o tráfego e o estado em memória e testamos os controles de autenticação, sessão e plataforma.
- Teste das APIs de back-end. Levamos ao servidor os endpoints descobertos, buscando falhas de autorização e vazamento de dados que o cliente não expõe sozinho.
- Consolidação e relatório. Cada achado é ligado ao requisito da MASVS correspondente, com evidência, impacto e orientação de remediação.
Essa cadeia é o que garante a rastreabilidade: no relatório final, cada afirmação técnica aponta para uma etapa executada e um requisito nomeado.
Pentest mobile testa só o aplicativo?
Não. Esse é o mal-entendido mais comum. O aplicativo mobile é a metade cliente de um sistema; a outra metade são as APIs de back-end que ele consome. A maior parte da lógica de negócio, da autorização e do acesso a dados vive no servidor, não no dispositivo.
Por isso, um pentest mobile completo sempre inclui o teste das APIs por trás do app. Controles do lado do cliente — validação de formulário, ocultação de botões, checagens locais — são conveniência de interface, não segurança: um atacante que controla o dispositivo os ignora e fala direto com a API. Falhas de autorização no servidor, respostas que vazam dados de outros usuários e endpoints sem controle de acesso adequado só aparecem quando o back-end entra no escopo. O aplicativo é a porta; a API é onde estão os dados.
Android e iOS: o que muda no teste?
As categorias da MASVS são as mesmas para as duas plataformas, mas as técnicas do MASTG divergem porque os sistemas operacionais, os formatos de binário e os mecanismos de proteção são diferentes.
| Aspecto | Android | iOS |
|---|---|---|
| Formato do pacote | APK/AAB (bytecode DEX, código nativo) | IPA (binário Mach-O, aplicação assinada) |
| Armazenamento seguro | Android Keystore | Keychain e Data Protection |
| Análise estática | Descompilação de DEX/Smali, inspeção do Manifesto | Análise do Mach-O, class-dump, inspeção do Info.plist |
| Superfície de plataforma | Activities, Services, Broadcast Receivers, Content Providers, deep links | URL schemes, Universal Links, extensões, pasteboard |
| Ambiente de teste | Emulador ou dispositivo com root; app geralmente mais aberto à instrumentação | Dispositivo com jailbreak costuma ser necessário; ecossistema mais fechado |
| Distribuição | Sideload de APK é direto | Distribuição fora da App Store exige provisionamento e assinatura |
Na prática, o Android tende a facilitar a análise estática e a instrumentação, pela abertura do sistema e pela facilidade de descompilar o bytecode. O iOS impõe mais atrito operacional — o ambiente fechado, a assinatura de código e a necessidade frequente de um dispositivo com jailbreak tornam a preparação mais trabalhosa. Um aplicativo que existe nas duas plataformas quase sempre compartilha o mesmo back-end, mas raramente compartilha o mesmo conjunto de falhas do lado do cliente: cada binário é avaliado por si.
Como a Berghem executa
A Berghem conduz o pentest mobile guiado pela OWASP MASVS e pelo MASTG, com escopo definido por categoria e ajustado ao modelo de ameaça de cada aplicativo. O teste combina análise estática do binário, análise dinâmica com instrumentação em tempo de execução e o teste das APIs de back-end que o app consome — porque avaliar só o cliente deixa de fora onde estão os dados. O detalhamento da abordagem, dos entregáveis e do escopo está na nossa página de pentest de aplicações mobile Android e iOS.
Como o aplicativo raramente vive isolado, conectamos o teste mobile às demais frentes técnicas da mesma organização — pentest de API, pentest de rede, pentest de cloud e exercícios de Red Team — e às trilhas de conformidade que dependem dessas evidências, como a adequação à LGPD e o PCI DSS. Aplicativos que processam pagamentos em dispositivos comuns entram no escopo do PCI MPoC. Como empresa de segurança da informação em São Paulo, ajustamos profundidade, plataformas e cronograma ao perfil de risco de cada operação.
A Berghem é uma empresa de pentest brasileira, sediada em São Paulo, que executa testes de invasão manuais orientados por objetivo adversarial.
Perguntas frequentes
Preciso entregar o código-fonte para um pentest mobile?
Não é obrigatório. Um pentest mobile pode ser conduzido apenas com o binário (APK ou IPA), em abordagem black ou gray box, já que a análise estática descompila o aplicativo. Entregar código-fonte, credenciais de teste e documentação das APIs aumenta a cobertura e a profundidade do teste.
O teste precisa de um dispositivo com root ou jailbreak?
Em geral, sim, para a análise dinâmica. Root no Android e jailbreak no iOS liberam a instrumentação em tempo de execução, o acesso ao sistema de arquivos do app e a interceptação de tráfego protegido por pinning. Esse é o cenário realista de um atacante que controla o próprio aparelho.
A detecção de root e jailbreak protege o aplicativo?
Ela eleva o custo do ataque, mas não é uma barreira definitiva. Detecção de root/jailbreak, anti-debug e anti-tampering — a categoria de resiliência da MASVS — atrasam um atacante e são úteis em apps financeiros. Nenhum desses controles substitui a segurança do servidor: autorização e proteção dos dados precisam ser garantidas na API.