$ cat /security
Security posture
Este site é também um projeto de segurança. Abaixo estão os controles aplicados nele e o modelo de ameaças que os justifica.
Controles
- Headers de segurança
- nosniff, X-Frame-Options DENY, HSTS, Referrer-Policy e Permissions-Policy na API e no site.
- Terminal sem shell
- O terminal compara cada entrada com uma lista fechada de comandos. Nada é executado no servidor, e encadear comandos (;, &&, |) não funciona.
- Rate limiting
- Contato: 5 mensagens/hora por IP. Terminal: 20 comandos a cada 10 s por conexão. CTF: 10 tentativas a cada 10 min.
- Validação estrita
- Toda entrada passa por modelos Pydantic, com tamanho máximo e formato definidos.
- Anti-bot
- O formulário de contato tem um campo honeypot invisível. Bots que o preenchem recebem 202, mas nada é gravado.
- Comparação em tempo constante
- A flag do CTF é comparada com hmac.compare_digest, sem vazar informação por timing.
- Containers sem root
- API e site rodam com usuários sem privilégios nas imagens Docker.
- CI com segurança
- Cada push roda ruff, bandit (SAST), pytest, lint e build do Next e gitleaks para segredos.
Threat model
| Ameaça | Mitigação |
|---|---|
| Spam no contato | Honeypot + rate limit + validação |
| Injeção de comandos no terminal | Whitelist, sem subprocess, sem eval |
| Força bruta na flag | Rate limit por IP + comparação em tempo constante |
| Clickjacking | X-Frame-Options DENY |
| XSS | React escapa a saída; handles do CTF aceitam só [A-Za-z0-9_.-] |
| Vazamento de segredos | gitleaks no CI e variáveis de ambiente fora do repositório |
| Abuso do WebSocket | Linhas com até 200 caracteres e limite de comandos por conexão |
Achou algo? Veja o security.txt. Gosta de desafios? Tente o mini-CTF.