Capstone: pentest em app próprio (ético)
- ⬜🚪 Zero Trust e mTLS: verificar sempre, nunca confiar na rede(Security Engineering)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
O projeto
| Entregável | O que prova |
|---|---|
| Escopo e autorização por escrito | Você sabe que teste fora do escopo é ataque |
| Modelo de ameaça antes dos testes | O trabalho é dirigido, não tentativa aleatória |
| Achados com passos de reprodução | Alguém consegue confirmar e corrigir |
| Severidade justificada | Você distingue o que dá acesso do que é incômodo |
| Correção proposta e verificada | O ciclo fechou — encontrar sem corrigir é meio trabalho |
| Teste de regressão do achado | A correção não será desfeita em silêncio |
Pegue uma aplicação que você construiu (ou o capstone do Trail 21 API Design) e faça um pentest completo: recon → scan → exploit → relatório → fix → retest. Entregável: repositório com SECURITY_REPORT.md + PRs de correção + regression tests.
Só atacar app que você tem autorização explícita pra atacar (seu próprio projeto, ambiente de teste, bug bounty program com escopo claro). Atacar sem autorização é crime.
Ferramentas essenciais
- Burp Suite Community: proxy + intruder + repeater. Instalar CA cert pra HTTPS.
- nuclei: scanner YAML-driven com 8000+ templates de vulns conhecidas.
- ffuf: fuzzing de URLs/params (encontrar endpoints hidden, testar IDOR).
- sqlmap: automatizar SQLi discovery + exploitation.
- nmap: port scan + service detection.
- nikto: scanner web clássico.
- httpx + subfinder: recon de subdomains vivos.
- git-dumper: se exposto, dump do source.
Passo a passo do capstone
# 1. RECON passivo (antes de tocar no alvo)
subfinder -d seuapp.com | httpx
# OSINT: shodan, censys, GitHub dorks (filename:.env, "password")
# 2. SCANNING automatizado
nmap -sV -sC -p- seuapp.com
nuclei -u https://seuapp.com -severity medium,high,critical
nikto -h https://seuapp.com
# 3. ENUMERATION
ffuf -w wordlists/common.txt -u https://seuapp.com/FUZZ
# Manualmente: Burp → spider → todas rotas no sitemap
# 4. EXPLOITATION (testar cada categoria OWASP)
# - IDOR: Burp Intruder trocando user_id em URLs
# - SQLi: sqlmap -u "https://app/users?id=1" --dbs
# - XSS: payloads em input fields, testar refletido/stored/DOM
# - SSRF: tentar fetch pra 169.254.169.254 (metadata AWS)
# - Auth: /admin sem login, JWT alg:none, etc.
# 5. POST-EXPLOITATION (impacto — sem exfiltrar dados reais)
# - Elevation lateral: user nivel N acessa dados de N+1?
# - Horizontal: user A acessa dados de user B?
# - Data exfil: qual API vaza email/PII sem authz?
# 6. REPORT (SECURITY_REPORT.md)
# Pra CADA achado: título, CVSS, reproduction steps (curl), impacto, fix
# 7. FIX + REGRESSION TEST
# PR: código + test que falharia se regredirO que precisa estar definido antes de iniciar o teste do capstone?
Template de entry de relatório
## FFV-001: Broken Access Control em /orders/:id (IDOR)
**Severity:** High (CVSS 8.1 — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
**Location:** GET /api/v1/orders/:id
**Discovered:** 2026-04-20
**Status:** Fixed em PR #42
### Description
Endpoint retorna qualquer order sem verificar que pertence ao user autenticado.
Um user A consegue ler todas as orders de user B incrementando o id.
### Proof of Concept
\`\`\`bash
# Login como user A (order_id=100)
curl -H "Authorization: Bearer $TOKEN_A" https://app.com/api/v1/orders/100
# → 200 OK, retorna order de A
# User A tenta order 101 (de outro user)
curl -H "Authorization: Bearer $TOKEN_A" https://app.com/api/v1/orders/101
# → 200 OK, VAZAMENTO — retorna order que NÃO é do user A
\`\`\`
### Impact
Vazamento massivo de dados de outros clientes (email, endereço, total pago).
LGPD Art. 46 — incidente de dados pessoais.
### Fix Applied (PR #42)
\`\`\`typescript
- const order = await db.order.findUnique({ where: { id } });
+ const order = await db.order.findFirst({
+ where: { id, userId: req.user.id }
+ });
+ if (!order) return new Response('not found', { status: 404 });
\`\`\`
### Regression Test
\`\`\`typescript
it('GET /orders/:id retorna 404 se order não pertence ao user', async () => {
const orderB = await createOrder({ userId: 'userB' });
const res = await fetch('/orders/' + orderB.id, {
headers: { Authorization: 'Bearer ' + tokenA }
});
expect(res.status).toBe(404);
});
\`\`\`
### Retest
Reaplicado PoC após fix: 404 retornado corretamente. ✅O que você vai aprender fazendo
- Como atacante REALMENTE pensa — não é gênio, é sistemático.
- A maioria das vulns não precisa de 0-day; é falha de design/review.
- Gap entre "parece ok" e "é ok" — ferramentas encontram coisas óbvias que escaparam do code review.
- Como priorizar: CVSS + exploitability + blast radius.
- Valor de regression test — se não testa, regride.
Este capstone é aplicação pura de tudo da trilha. Ao terminar, você tem relatório profissional que poderia entregar pra cliente real — e sabe como seu próprio código parece pro atacante.
Perguntas frequentes
❓ Por onde começar a testar a própria aplicação?
❓ Ferramenta automática encontra o que importa?
❓ O que fazer com o achado?
Fixando
Qual achado tem mais valor num relatório de teste?
Por que o capstone pede o relatório e não apenas a lista de falhas?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…