Para qualquer funcionalidade, desenhe o fluxo e marque cada fronteira:

[ navegador (NÃO confiável) ] ──req──> [ API (valida tudo) ] ──> [ banco (RLS) ]
        │ o usuário controla:                │ o servidor decide:
        │ campos, headers, cookies, ordem     │ authN, authZ, validação, preço/estado

Em cada seta, pergunte: "o que passa aqui é confiável? o que pode ser adulterado? quem valida?" Esse desenho é o que separa testar às cegas de testar com método.

PARTE B — Catálogo de vulnerabilidades web (as 11 classes)

Cada card: o que é · padrão (entrada→saída) · como testar · como corrigir · onde praticar (PortSwigger + seu projeto). Estude uma por vez.

V1 — Broken Access Control / IDOR / BOLA (OWASP A01) 🔴 a nº 1 hoje

• O que é: o servidor entrega um recurso/ação sem checar se você tem permissão (papel ou propriedade).
• Padrão: entrada = um id ou uma rota; processamento = não verifica autorização; saída = dado/ação de outro.
• Testar: troque ?id=123→124; acesse /admin com token de usuário comum; chame o endpoint direto (sem passar pela UI).
• Corrigir: checar ownership e role no servidor em toda ação; RLS no banco; negar por padrão.
• Praticar: PortSwigger Access control · seus Ex. 7, 26, 29.

V2 — Injection: SQL & Command (OWASP A03) 🔴

• O que é: a entrada é misturada a um comando (SQL, shell) e executada como instrução.
• Padrão: entrada concatenada num comando → o servidor executa o que o atacante escreveu.
• Testar: em campos/params, ' OR '1'='1, ; sleep 5, aspas que quebram a query; blind por tempo (SLEEP).
• Corrigir: consultas parametrizadas (nunca concatenar); evitar shell com input; allowlist; WAF como camada extra.
• Praticar: PortSwigger SQL injection · seus Ex. 54, 55 (blind/second-order) + DVWA.

V3 — Cross-Site Scripting (XSS) (OWASP A03) 🔴

• O que é: a entrada do atacante é devolvida na página e o navegador da vítima a executa como JavaScript.
• Tipos: refletido (na resposta imediata), armazenado (salvo e servido depois — o pior), DOM (no JS do cliente).
• Testar: <script>alert(1)</script>, <img src=x onerror=alert(1)> em campos que voltam à tela; ver se escapa.
• Corrigir: escapar/sanitizar a saída por contexto; nunca dangerouslySetInnerHTML/innerHTML com input; CSP; cookie HttpOnly.
• Praticar: PortSwigger XSS · seu Ex. 33 (XSS armazenado via IA — a cadeia clássica).

V4 — Cross-Site Request Forgery (CSRF)

• O que é: o site do atacante faz o navegador da vítima enviar uma requisição autenticada sem ela saber (o cookie vai junto, automático).
• Padrão: a vítima logada visita uma página maliciosa que dispara um POST ao seu app.
• Testar: montar um <form> auto-submit para um endpoint que muda estado e ver se é aceito sem token (seu Ex. 14).
• Corrigir: CSRF token por requisição; cookie SameSite=Lax/Strict; validar Origin/Referer em POSTs.
• Praticar: PortSwigger CSRF · seu Ex. 14.

V5 — Server-Side Request Forgery (SSRF) (OWASP A10)

• O que é: o servidor busca uma URL fornecida pelo usuário sem validar → alcança recursos internos.
• Padrão: entrada = URL; o servidor a busca; saída = conteúdo interno (ex.: 169.254.169.254 = credenciais na nuvem).
• Testar: apontar um parâmetro de URL para 127.0.0.1, IPs internos, file://, o metadata endpoint.
• Corrigir: allowlist de destinos; bloquear ranges privados/link-local e esquemas perigosos; timeout curto.
• Praticar: PortSwigger SSRF · seu Ex. 44.

V6 — Falhas de autenticação (OWASP A07) 🔴

• O que é: login fraco: sem rate limit/lockout, hash rápido, enumeração por timing, JWT mal validado.
• Testar: muitas tentativas sem bloqueio; medir tempo (e-mail válido × inválido); JWT sem exp/alg:none.
• Corrigir: lockout + rate limit; bcrypt/argon2 + tempo constante; 2FA; validar exp/role/assinatura; HIBP.
• Praticar: PortSwigger Authentication + JWT attacks · seus Ex. 4, 12, 28.

V7 — Exposição de informação (OWASP A01/A05)

• O que é: o app vaza detalhes que ajudam o atacante: stack traces, versões, arquitetura, PII em respostas.
• Testar: ler headers (x-powered-by), campos extras no JSON (source: "database"), mensagens de erro verbosas.
• Corrigir: erros genéricos (logar o real só no servidor); remover headers/campos reveladores; poweredByHeader:false.
• Praticar: PortSwigger Information disclosure · seus Ex. 1, 35.

V8 — Upload inseguro

• O que é: aceitar arquivo sem validar → webshell, polyglot, zip slip, ou servir conteúdo executável.
• Testar: subir .php.jpg, arquivo com Content-Type falso; tentar acessá-lo e ver se executa.
• Corrigir: validar magic bytes (não a extensão); storage isolado sem execução; renomear; limitar tamanho; varredura.
• Praticar: PortSwigger File upload · seu Ex. 45 (Guia Multi-Stack).

V9 — Path traversal

• O que é: manipular um caminho de arquivo (../../etc/passwd) para ler fora do diretório permitido.
• Testar: ../, versões codificadas (%2e%2e%2f, duplo-encode) num parâmetro de arquivo/mídia.
• Corrigir: normalizar e validar o caminho; allowlist; servir de um diretório fixo; defesa em camadas (seu Ex. 5: 404→400→403).
• Praticar: PortSwigger Path traversal · seu Ex. 5.

V10 — Security Misconfiguration (OWASP A05)

• O que é: configuração frouxa: sem HSTS, CSP com https://*, CORS *, TLS 1.0, defaults abertos, painel exposto.
• Testar: ler headers de segurança; testar CORS com Origin malicioso; versão de TLS (seu Ex. 11).
• Corrigir: headers completos (CSP real, HSTS, X-Frame-Options, nosniff); CORS allowlist; TLS mínimo 1.2; fechar o que não usa.
• Praticar: PortSwigger CORS / Host header · seus Ex. 1, 10, 11.

V11 — Lógica de negócio 🧠 a mais subestimada

• O que é: o fluxo funciona "como programado", mas a regra de negócio pode ser abusada: preço vindo do cliente, cupom infinito, race condition, quantidade negativa, pular etapa.
• Padrão: não é um payload — é usar o sistema de um jeito que o dev não previu.
• Testar: enviar preço=0,01; repetir uma ação em paralelo (race, seu Ex. 18); pular a etapa de pagamento; valores-limite.
• Corrigir: validar invariantes no servidor; idempotência; buscar preço/estado no backend; máquinas de estado explícitas.
• Praticar: PortSwigger Business logic vulnerabilities · seus Ex. 3, 13, 18, 27.

PARTE C — Metodologia de teste web (como um profissional testa)

Baseada no OWASP Web Security Testing Guide (WSTG) e no ciclo de pentest (Fase 2). Para qualquer app autorizada:

1. RECON        → tecnologia, headers, robots, subdomínios, endpoints (Ex. 1, 2)
2. MAPEAR       → toda a superfície: rotas, params, formulários, APIs, autenticação
3. TESTAR       → por categoria (as 11 classes da Parte B), do menos ao mais intrusivo
4. VALIDAR      → confirmar a falha de forma controlada (prova mínima, sem estragar)
5. AVALIAR      → impacto real: dá dinheiro? dados? acesso? (severidade P0–P3)
6. RELATAR      → vulnerabilidade + evidência + impacto + correção

Ordem prática: comece pelos testes de leitura (recon, headers, IDOR por leitura), depois os que criam dado de teste (pentest_), e só em localhost os destrutivos. É o semáforo do seu tutorial aplicado à web.

PARTE D — Plano de labs (teoria + prática juntas)

Faça na ordem; cada linha combina um lab guiado (PortSwigger, onde o ataque funciona) com o exercício equivalente no seu sistema.

Ferramenta companheira: Burp Suite Community (o proxy que intercepta e edita requisições) — instale e use do lab 1 em diante. É a ferramenta central de teste web.

PARTE E — Autoavaliação ✅

Responda de memória:

1. Quais são as três perguntas do "mapa de confiança"?
2. Diferencie Broken Access Control (IDOR) de uma falha de autenticação.
3. No padrão entrada→saída, por que XSS e SQLi são "a mesma história"?
4. O que é CSRF e por que SameSite ajuda a evitá-lo?
5. Por que a lógica de negócio é difícil de testar com ferramenta automática?
6. Cite a ordem das 6 etapas da metodologia de teste web.
7. Um endpoint responde 200 com dados de outro usuário ao trocar o id. Qual classe é, e qual a correção?

1. Onde estão os pontos de confiança? O que o usuário controla? O que o servidor deveria validar? (Parte A/mentalidade).
2. Autenticação falha em provar quem você é (login fraco). Access control/IDOR falha em checar se você pode acessar aquele recurso, mesmo autenticado (V1 × V6).
3. Ambas: entrada do atacante é executada como código/instrução na saída (XSS: JS no navegador; SQLi: comando no banco). Causa: não separou dado de código (Módulo 0, 0.12).
4. CSRF = fazer o navegador da vítima enviar uma requisição autenticada sem ela saber. SameSite impede o cookie de ser enviado em requisições vindas de outro site (V4).
5. Porque não é um payload — é abusar da regra de negócio. A ferramenta não sabe que "preço=0,01" é errado; só um humano que entende o fluxo percebe (V11).
6. Recon → Mapear → Testar → Validar → Avaliar impacto → Relatar (Parte C).
7. Broken Access Control / IDOR (BOLA). Correção: checar ownership no servidor (o recurso é daquele usuário?) + RLS no banco; negar por padrão (V1).</details>

Checklist prático:

[ ] Desenhei o mapa de confiança de uma funcionalidade real
[ ] Resolvi ao menos 1 lab PortSwigger de cada: access control, auth, SQLi, XSS
[ ] Testei IDOR trocando um id em alvo autorizado
[ ] Reproduzi a cadeia de XSS armazenado (Ex. 33) e entendi cada elo
[ ] Instalei o Burp e interceptei/editei uma requisição
[ ] Achei 1 vulnerabilidade de lógica de negócio (preço/race/etapa)
[ ] Escrevi 1 mini-relatório: vuln + evidência + impacto + correção

Conclusão: 5/7 do quiz + ≥ 6 itens do checklist. Este é o módulo para levar a sério — é a base da sua especialização.