Instale Python (
python --version). Rode contra alvos seus/autorizados ou apenas leia (labs 4–5 são leitura). Os snippets são ilustrativos e curtos — o objetivo é entender, não produzir ferramenta.
Lab 1 — Bash: mini-recon automatizado (🟡 leitura de status)
BASE="https://SEU-ALVO-AUTORIZADO"
for p in "/api/feed" "/api/leads" "/api/admin" "/robots.txt"; do
curl -s -o /dev/null -w "$p -> %{http_code}\n" "$BASE$p"
done
Faça: troque a lista de paths. Lição: você automatizou o Ex. 2 (matriz de superfície). Qualquer 200 em algo que deveria ser protegido = achado.
Lab 2 — Python: request + ler JSON (🟢)
import requests
r = requests.get("https://SEU-ALVO/api/feed?limit=2")
data = r.json()
print("Campos:", list(data.keys())) # que campos vieram?
print("source:", data.get("source")) # vaza arquitetura? (Ex. 35)
Faça: rode e leia a saída. Lição: é a base de toda automação/PoC — pedir e interpretar dados.
Lab 3 — Python: por que SHA-256 é ruim para senha (🟢 conceitual)
import hashlib, time
t=time.time()
for i in range(1_000_000):
hashlib.sha256(f"senha{i}".encode()).hexdigest()
print("1 milhão de SHA-256 em", round(time.time()-t,2), "s") # muito rápido!
Observe: o tempo minúsculo → uma GPU faz bilhões/s. Lição: por isso senha usa bcrypt/argon2 (lentos, com salt), não SHA-256 (Ex. 28). Você acabou de sentir o problema.
Lab 4 — SQL: injeção vs parametrização (🟢 leitura — NÃO rode em prod)
# VULNERÁVEL — o input é colado na query (vira comando):
query = "SELECT * FROM users WHERE email = '" + entrada + "'"
# se entrada = ' OR '1'='1 → a query retorna TODOS os usuários
# SEGURO — o input entra como parâmetro (é sempre tratado como DADO):
query = "SELECT * FROM users WHERE email = $1" # $1 = entrada, nunca interpretada como SQL
Lição: SQLi é literalmente essa diferença de uma linha. Ao revisar código, procure concatenação de input em query (Ex. 54).
Lab 5 — Ler JS de um bundle procurando problema (🟢) — liga ao Ex. 1/25/33
No navegador do seu site: F12 → Sources/Network → abra um arquivo .js e procure (Ctrl+F):
sk- | eyJ | secret | password | apiKey | dangerouslySetInnerHTML | eval(
Observe: apareceu algum segredo ou render inseguro? Lição: é a auditoria de bundle (Ex. 25) e a origem do XSS (Ex. 33), lida no código-fonte.
Lab 6 — A IA como par de revisão (🟢) — para o vibe coder
Pegue um trecho de código (seu ou gerado por IA) e peça:
"Revise este código como um pentester. Aponte: onde confia em input do cliente, autorização que deveria estar no servidor, segredos hardcoded, injeção (SQL/XSS/command) e o que validar. Liste por severidade."
Lição: a IA acelera a revisão — mas você precisa entender a resposta para julgar. Este módulo te dá esse entendimento.
Lab 7 — Git: o segredo que não some (🟡 leitura do seu repo) — liga ao Ex. 32
# .gitignore protege arquivos sensíveis ANTES do commit:
grep -E "env|key|secret|wrangler" .gitignore || echo "ATENÇÃO: .env/segredos podem não estar protegidos"
# procurar segredo no HISTÓRICO (não só no estado atual):
git log --all -p 2>/dev/null | grep -iE "api[_-]?key|password|sk-|eyJ" | head
# ferramenta dedicada (se instalada):
gitleaks detect --source . 2>/dev/null | tail -5
Observe: aparece algum segredo em commits antigos? Lição: o histórico é permanente — segredo commitado exige rotacionar + limpar histórico, não só apagar o arquivo (A.8).
Lab 8 — Env vars & dependências (🟡)
# criar um .env de teste e garantir que ele NÃO vai para o git:
echo "API_KEY=troque_por_um_valor" > .env
echo ".env" >> .gitignore
git check-ignore .env && echo "OK: .env está sendo ignorado pelo git"
# auditar dependências vulneráveis (num projeto Node):
npm audit --audit-level=high 2>/dev/null | tail -15 || echo "sem package.json aqui — rode dentro do projeto"
Observe: o .env ignorado; vulnerabilidades no npm audit. Lição: segredo fora do código (A.9) + dependências auditadas (A.10).