O Vazamento no Comentário: Encontrando um Endpoint de Debug Escondido no Código-Fonte HTML
O desafio
Este painel de faturamento parece limpo, mas um desenvolvedor deixou uma anotação no HTML que nunca é removida antes de publicar. Abra o código-fonte, leia o comentário e envie o endpoint de debug que ele menciona.
O que você vai aprender
- Abrir e ler o "Ver código-fonte" da página em vez de confiar na saída renderizada
- Reconhecer que comentários HTML são entregues ao cliente e nunca são confidenciais
- Identificar uma anotação TODO de desenvolvedor que vaza um endpoint interno e uma chave
- Extrair o caminho exato de uma URL a partir de um texto livre de comentário
- Explicar por que rotas de debug e anotações devem ser removidas antes da produção
Habilidades testadas
Pré-requisitos
- Saber abrir o "Ver código-fonte" em um navegador
- Familiaridade básica com caminhos de URL e query strings
Como funciona
Quando um navegador renderiza uma página, ele mostra o resultado visual: títulos, textos, botões. Ele não mostra tudo o que chegou pela rede. Comentários HTML, escritos como <!-- ... -->, são removidos da visualização renderizada, mas são enviados literalmente a cada visitante. Qualquer um pode lê-los escolhendo Ver código-fonte ou abrindo a resposta da rede. Para fins de segurança, eles são completamente públicos.
Desenvolvedores costumam deixar comentários como lembretes: um TODO para remover uma rota de debug, uma anotação sobre um recurso inacabado, às vezes até uma credencial. Neste desafio o comentário diz TODO remove /api/v2/debug?key=DEV-9931 before release - no auth on this route yet. Essa única linha conta ao atacante três coisas: que existe um endpoint não documentado, onde ele fica e que não tem autenticação, além de incluir uma chave válida. Nada disso é visível na página, então um desenvolvedor pode presumir que está escondido - mas ele é entregue a todo mundo.
A correção não é esconder melhor o comentário. É nunca colocar anotações sensíveis em markup entregue ao cliente. Tudo o que o servidor envia ao navegador - HTML, comentários, campos ocultos, JavaScript - deve ser tratado como totalmente legível pelo usuário, porque é.
Erros comuns
- Confiar na página renderizada. Olhar apenas para o que o navegador desenha e presumir que nada mais foi enviado. O dado interessante está no código-fonte, não na visualização.
- Pular os comentários. Vasculhar o código-fonte em busca de elementos visíveis, mas ignorar os blocos
<!-- -->, que é exatamente onde o vazamento está aqui. - Enviar o fragmento errado. Digitar apenas a chave (
DEV-9931) em vez do caminho do endpoint que foi pedido. - Presumir que uma rota escondida é uma rota segura. Tratar "não linkada na interface" como "inacessível". O comentário prova o contrário.
Como se proteger
Trate toda a resposta HTML como pública e mantenha segredos e referências internas totalmente fora dela. Remover comentários no momento do build e eliminar rotas de debug antes do lançamento é um seguro barato contra toda essa classe de vazamento.
- Remova comentários HTML dos builds de produção usando seu bundler ou motor de templates.
- Nunca escreva credenciais, chaves, URLs internas ou anotações sobre recursos inacabados no markup, nem mesmo em comentários.
- Remova ou exija autenticação em endpoints de debug e internos em vez de confiar que eles estão apenas sem link.
- Adicione uma revisão ou verificação de CI que falhe o build quando
TODO, chaves ou caminhos internos aparecerem no HTML publicado.