Escopo, tipos de teste e limitações
A.1 Tipos de pentest
Um teste de intrusão (pentest) pode ser feito com mais ou menos informação sobre o alvo:
| Tipo | O que é | O que exige |
|---|---|---|
| Black box (caixa-preta) | O testador parte só do endereço público, como um atacante externo. Descobre tudo de fora. | Apenas a URL. |
| Gray box (caixa-cinza) | O testador recebe algum acesso parcial: um usuário de teste, documentação da API, descrição da arquitetura. | URL + credenciais ou informações limitadas. |
| White box (caixa-branca) | O testador tem o código-fonte e/ou acesso administrativo. Permite análise estática de código (SAST) e de dependências (SCA), com cobertura muito maior. | Código-fonte + acessos. |
Os tiers do produto se posicionam assim:
- Essencial — black box: OSINT e testes não-invasivos.
- Completo — black box + fases invasivas de aplicação (SQL Injection, XSS, IDOR) e verificação de conformidade.
- Avançado — o acima + white box: SAST e SCA sobre o código-fonte que a contratante fornece.
A.2 As duas camadas de um sistema web
- Camada de aplicação — o que a contratante construiu: telas, regras de negócio, autenticação, permissões, chamadas de API, configuração do banco de dados. É esta camada que o dono do sistema controla e pode autorizar a testar.
- Camada de infraestrutura — os servidores, a rede e a própria plataforma que hospedam a aplicação. Quando o alvo está em plataforma de hospedagem gerenciada (por exemplo Lovable, Vercel, Netlify, Supabase, Firebase, WordPress.com, GitHub Pages, Cloudflare Pages), essa camada pertence ao provedor da plataforma e é compartilhada entre seus clientes. A responsabilidade por essa camada é do provedor da plataforma; a contratante responde pela camada de aplicação. Esta auditoria concentra-se na camada de aplicação — a lógica, a autenticação, as permissões e a configuração sob controle da contratante.
A.3 O que testamos e o que não testamos
| Testamos (camada de aplicação) | Não testamos (infraestrutura da plataforma) |
|---|---|
| Cabeçalhos de segurança e configuração HTTPS/TLS | Técnicas de evasão de WAF / firewall da plataforma |
| CORS, cookies, segredos expostos no código do navegador | Negação de serviço (DoS), stress, SlowLoris |
| Falhas de autenticação e de autorização | Força bruta real de senhas em alto volume |
| IDOR — trocar um identificador e acessar dado de outro usuário | Upload de webshell / arquivo malicioso |
| SQL Injection, XSS, CSRF | Scanners automatizados de alto ruído (Nuclei, OWASP ZAP) — fora do self-service |
| Lógica de negócio (pular etapas, manipular preço ou quantidade) | Engenharia social, phishing, acesso físico |
| Rate-limiting (existe limite de tentativas?) | Análise de código-fonte (SAST/SCA) — só no tier Avançado |
| Conformidade com a LGPD no tratamento de dados pela aplicação | Qualquer teste destrutivo |
| Reconhecimento passivo: DNS, WHOIS, certificados, tecnologias | — |
A.4 Alvos em plataforma gerenciada
Quando a verificação técnica indica que o alvo está em plataforma de hospedagem gerenciada, o escopo ativo é o mesmo escopo de camada de aplicação de qualquer outro alvo — nenhuma fase é retirada por causa da plataforma. Testes destrutivos (indisponibilidade proposital, DoS, stress, SlowLoris, força bruta real de credenciais em volume, upload malicioso/webshell) nunca são executados, em nenhum tier, contra alvo nenhum. O que a plataforma gerenciada muda é o contexto: a infraestrutura (rede, servidor, WAF de borda) pertence à plataforma e é compartilhada entre seus clientes, de modo que achados na camada de infraestrutura estão fora do que a contratante controla e pode autorizar. O relatório final nomeia a plataforma detectada para deixar claro o contexto de hospedagem e lista as fases não executadas apenas por não fazerem parte do tier contratado.
A.5 Limitações gerais
- Retrato do momento. O relatório reflete o estado do alvo na data dos testes. Alterações posteriores de código ou configuração não estão cobertas.
- Ausência de achado não é garantia. Não encontrar uma vulnerabilidade não certifica que ela não exista.
- Black box não enxerga o código (exceto no tier Avançado). Falhas visíveis apenas no código — lógica interna, dependências desatualizadas, segredos no backend — podem não ser detectadas.
- Testes em produção podem ser mascarados. Não há ambiente de homologação separado; o WAF e os limites de requisição da plataforma podem bloquear ou distorcer parte dos testes, gerando resultados marcados como inconclusivos.