Pentest Mobile em Fintech: o que testamos no app além do OWASP MASVS

Categoria: Segurança Mobile | Pentest | Fintech Nível: Intermediário Ambiente: Laboratório controlado — cenário totalmente anonimizado, sem dados reais de clientes

---

Introdução

O seu app de banco está na Play Store com 4,8 estrelas. O time de engenharia faz code review, o pipeline roda SAST a cada push e o backend passou por um scan automatizado na última release. Ainda assim, quando um pentest mobile começa, a primeira coisa que o testador encontra costuma surpreender: os problemas mais graves não estão no backend — estão no app que você publicou.

Fintechs processam o tipo de ativo que adversários mais perseguem: dinheiro, dados bancários, tokens de sessão e PII em volume. O smartphone virou a interface principal desse fluxo, e a segurança mobile tem uma característica única: o código do app está no bolso do atacante. Diferente do backend, que você protege atrás de firewall e WAF, o APK/IPA é distribuído para milhões de dispositivos — qualquer um pode baixar, descompilar e estudar o seu app como quem lê um livro aberto.

Este material é preventivo e descreve, em cenário de laboratório anonimizado, o que um pentest mobile encontrou em uma fintech fictícia ("PayFlow") — e por que cada achado representa um risco real para qualquer empresa que movimente dinheiro por app.

---

1. Por que segurança mobile é diferente (a física do problema)

Antes dos findings, vale entender por que o app exige uma abordagem própria:

1. O atacante tem o binário. Backend é caixa-preta; app é caixa-branca. Com jadx, apktool ou MobSF, qualquer pessoa transforma um APK em código legível em minutos. Segredo que vive no app não é segredo — é tempo.
2. O dispositivo é hostil. O app roda em um ambiente que o usuário controla: com root, com hooking (Frida), com proxy interceptando o tráfego. Se o app confia no dispositivo, o atacante controla o app.
3. A API mobile é uma superfície paralela. Muitas fintechs mantêm endpoints específicos do app com controles mais fracos que os da web — e versões antigas da API continuam no ar anos depois.
4. O dano é direto. Vazamento de token de sessão, bypass de autenticação ou chave de API exposta em fintech significam acesso a saldo, transferência e dados bancários — não apenas "exposição de infraestrutura".

O OWASP Mobile Top 10 (2024) organiza bem o que mais se repete em testes reais: uso impróprio de credenciais (M1), comunicação insegura (M5), autenticação/autorização inseguras (M3), armazenamento inseguro de dados (M9) e proteções binárias insuficientes (M7) — exatamente os padrões que os findings abaixo reproduzem.

---

2. O cenário de laboratório: a fintech "PayFlow"

Para mostrar o fluxo completo, usamos um cenário fictício de laboratório: a PayFlow, fintech de pagamentos com 2 milhões de usuários ativos, app Android e iOS, movimentando Pix, cartões e contas digitais. Ela contratou um pentest mobile com a seguinte orientação: testar o app como um adversário real — baixar o APK, descompilar, analisar estaticamente e depois atacar a API por trás do app com um proxy.

O resultado: oito findings, todos com reprodução, todos classificados pelo impacto real para o negócio. Abaixo, os cinco mais representativos.

---

3. Os findings (cenário anonimizado)

Finding 1 — [CRÍTICO] Chave de API e segredo de assinatura hardcoded no APK

Na análise estática do APK (jadx + apkleaks), o testador encontrou uma API key de um serviço de pagamentos de terceiro e o segredo usado para assinar tokens JWT embutidos no código, em uma classe de configuração.

• Reprodução: extração do APK da Play Store → descompilação → strings/constantes em texto plano.
• Por que acontece: a equipe precisava de uma forma simples de autenticar o app contra o serviço e "escondeu" o segredo no código do cliente, acreditando que ofuscação bastava.
• Impacto: com o segredo de assinatura, um atacante forja tokens JWT e se passa por qualquer usuário — inclusive por usuários administrativos, se o backend não diferenciar o token do app do token de admin. A chave de terceiro permite gastar crédito do serviço de pagamento em nome da PayFlow.
• Lição: segredo que precisa viver no backend não pode viver no app. Qualquer credencial embarcada é, por definição, pública.
• OWASP Mobile Top 10 (2024): M1 (Improper Credential Usage) + M7 (Insufficient Binary Protections) — ofuscação não é controle de acesso.

Finding 2 — [ALTO] Sem certificate pinning: tráfego interceptável via proxy

O app validava apenas a cadeia de certificados do sistema operacional — sem certificate pinning. O testador conseguiu interceptar o tráfego por dois caminhos: a instalação da CA do Burp Suite no dispositivo funcionou porque o app confiava em CAs de usuário (comum em builds de desenvolvimento ou com networkSecurityConfig permissivo); em apps Android modernos (targetSdk ≥ 24), que não confiam em CAs de usuário por padrão, o caminho real é o bypass via Frida.

• Reprodução: proxy na rede → instalação de CA (builds de desenvolvimento/networkSecurityConfig permissivo) ou bypass via Frida → tráfego do app decodificado no Burp.
• Por que acontece: pinning dificulta o desenvolvimento (certificados de staging, testes em CI) e a equipe adiou a implementação.
• Impacto: em um cenário real, o mesmo tráfego interceptado contém tokens de sessão e payloads com dados bancários. O pinning não é uma defesa absoluta (um atacante com acesso ao dispositivo usa Frida para contornar), mas eleva o custo do ataque e impede a interceptação passiva em rede pública — a porta de entrada mais comum.
• Lição: pinning é higiene básica para app que movimenta dinheiro; sem ele, o app depende inteiramente do TLS do SO.
• OWASP Mobile Top 10 (2024): M5 (Insecure Communication).

Finding 3 — [ALTO] Tokens de sessão e dados bancários armazenados em texto plano no dispositivo

A análise dinâmica (dispositivo com acesso root + Frida) revelou que o app guardava o token de sessão e o último extrato consultado em SharedPreferences e em arquivos SQLite em texto plano — sem criptografia, sem Keychain/Keystore.

• Reprodução: navegar no app → inspecionar /data/data/<pacote>/shared_prefs e o SQLite local.
• Por que acontece: armazenar o token em memória persistente foi a solução rápida para manter o usuário logado sem reautenticar a cada abertura.
• Impacto: um dispositivo comprometido (malware/root), ou aparelho perdido/roubado sem bloqueio de tela/FBE ou com allowBackup=true (extração via adb backup), entrega o token de sessão — e, com ele, acesso à conta sem precisar de senha. Dados bancários armazenados localmente ampliam o dano de um simples roubo de celular.
• Lição: tokens devem viver em armazenamento seguro do SO (Keystore/Keychain), com curta duração; dados sensíveis não devem ser persistidos no dispositivo sem necessidade — e, se forem, criptografados com chave derivada do Keystore.
• OWASP Mobile Top 10 (2024): M9 (Insecure Data Storage).

Finding 4 — [ALTO] Endpoints de API mobile com controles mais fracos que os da web

O app conversava com uma API dedicada (api-mobile.payflow.app) que não exigia os mesmos controles da API web: rate limiting ausente, sem validação de versão do app e respostas com mais dados do que a tela precisa (ex.: o endpoint de saldo retornava também o histórico completo de transações e o CPF completo do usuário).

• Reprodução: análise estática revelou o endpoint; proxy mostrou o payload completo da resposta.
• Por que acontece: a API mobile foi criada depois, por outro time, com pressa de lançar — e ninguém revisou se os controles da API web valiam para ela.
• Impacto: a ausência de rate limiting abre caminho para enumeração de contas e ataques de força bruta; o excesso de dados na resposta transforma um endpoint legítimo em fonte de exfiltração para um atacante com token vazado (ou em cenário de acesso indevido).
• Lição: API mobile não é uma API diferente — é a mesma superfície de risco, com o agravante de ser descoberta com facilidade a partir do próprio app.
• OWASP Mobile Top 10 (2024): M3 (Insecure Authentication/Authorization) — rate limiting ausente e excesso de dados na resposta agravam o M3.

Finding 5 — [MÉDIO] Deep links manipuláveis (abertura de tela sensível sem validação de origem)

O app registrava deep links (payflow://transferencia?valor=...) e os abria sem validar a origem do intent/URL scheme. Em um cenário de ataque, um link malicioso disparado por SMS ou site comprometido podia abrir telas de transferência pré-preenchidas dentro do app autenticado.

• Reprodução: adb shell am start -a android.intent.action.VIEW -d "payflow://transferencia?valor=9999" em dispositivo com o app logado.
• Por que acontece: deep links foram implementados para campanhas de marketing e ninguém considerou o vetor de abuso.
• Impacto: a superfície é de engenharia social — o app autenticado executa uma ação sensível a partir de um gatilho externo. O risco real depende de validação de parâmetros e de confirmação na tela, mas a abertura direta de fluxos sensíveis por link é um padrão que deve ser bloqueado.
• Lição: deep links exigem allowlist de domínios (App Links/Universal Links), validação de parâmetros e, para ações sensíveis, confirmação explícita do usuário.
• OWASP Mobile Top 10 (2024): M4 (Insufficient Input/Output Validation) — superfície de entrada não validada a partir de origens externas.

---

4. Por que o scanner sozinho não encontra isso

Os findings acima têm um padrão comum: nenhum deles depende de uma vulnerabilidade do backend clássica (SQLi, RCE, XSS). São falhas de design do app e de lógica de negócio:

Um scan automatizado de backend não baixa o app, não descompila, não roda no dispositivo e não intercepta tráfego. Para segurança mobile, o scanner é só o começo — a parte que encontra os problemas está no trabalho manual guiado por raciocínio adversarial: "se eu fosse o atacante e tivesse o APK na mão, o que eu faria?".

---

5. O que um programa de segurança mobile maduro inclui (checklist prático)

Com base no cenário acima, o mínimo que uma fintech deve ter no programa mobile:

1. Análise estática automatizada no CI (MobSF, semgrep para Android/iOS) — pega segredos, permissões excessivas, componentes exportados e WebViews inseguros a cada build.
2. Gerenciamento de segredos rigoroso — nenhuma credencial no binário; segredos no backend, rotacionados, com detecção de vazamento (gitleaks e similares no repositório).
3. Certificate pinning no app de produção, com plano de rotação e bypass apenas em builds de desenvolvimento.
4. Armazenamento seguro — tokens no Keystore/Keychain, dados sensíveis não persistidos sem necessidade, FLAG_SECURE em telas sensíveis (bloqueio de screenshot).
5. API mobile tratada como superfície de risco própria — mesmo rigor de autenticação, rate limiting e mínima exposição de dados; versões antigas descontinuadas.
6. Pentest mobile periódico (a cada release relevante ou no mínimo anual) com análise estática + dinâmica + teste de API — executado por quem conhece o fluxo do negócio, não apenas por ferramenta.
7. Treinamento do time — os findings mais comuns (hardcoded secrets, armazenamento inseguro) são falhas de hábito, não de tecnologia.

---

6. Por que contratar um pentest mobile (e não "um scanner")

O valor do pentest mobile não está em "rodar uma ferramenta" — está na leitura adversarial de um binário que qualquer um pode baixar. Para uma fintech, o custo de um finding crítico não remediado é medido em saldo de cliente e em confiança regulatória: o Banco Central (Bacen) observa a gestão de segurança de instituições de pagamento, e incidentes com dados bancários têm consequências que vão além do reparo técnico.

O cenário da PayFlow é laboratório — mas cada um dos oito findings reproduz padrões que se repetem em apps reais do mercado financeiro. A diferença entre a fintech que descobre isso em um teste e a que descobre em um incidente é exatamente o valor do pentest.

---

Este artigo descreve um cenário de laboratório totalmente fictício, construído para fins educacionais. Nenhum dado real de cliente foi utilizado. A exploração de vulnerabilidades em sistemas sem autorização explícita é ilegal.