[ Visão Geral das Vulnerabilidades ]

Cabeçalhos HTTP: a camada de metadados da web. Essenciais, mas frequentemente um campo minado de falhas de segurança. Esta seção é o seu scan inicial, mapeando as categorias de vulnerabilidades mais comuns em pentests. O gráfico abaixo plota a frequência relativa, destacando os alvos primários.

[+] Frequência Relativa de Falhas em HTTP Headers (Dados Ilustrativos)

[ Vetores de Ataque por Header ]

Cada header é uma porta de entrada potencial. A confiança da aplicação é a chave que usamos. Aqui, detalhamos os headers mais explorados. Expanda cada um para analisar a sua função, o método de manipulação e os payloads para exploração.

Host / X-Forwarded-Host

+

[Finalidade]: Especifica o domínio do servidor. Essencial para roteamento em Virtual Hosts.

[Vulnerabilidade]: Confiança cega neste header leva a injeção. A aplicação pode usá-lo para gerar links (reset de senha), importar scripts ou redirecionar. A manipulação resulta em Web Cache Poisoning, redirecionamentos maliciosos ou SSRF.

[Payload: Password Reset Poisoning]:

GET /password-reset HTTP/1.1
Host: evil-attacker.com

-- Se o link de reset for gerado com base no 'Host', o e-mail da vítima apontará para o domínio do atacante.

X-Forwarded-For / X-Real-IP / etc.

+

[Finalidade]: Usado por proxies para passar o IP original do cliente.

[Vulnerabilidade]: Se a aplicação usa este header para controle de acesso (IP Whitelisting), um atacante pode forjá-lo para burlar a proteção e acessar áreas restritas como painéis de admin.

[Payload: Bypass de IP Whitelist]:

GET /admin HTTP/1.1
Host: vulnerable-app.com
X-Forwarded-For: 127.0.0.1

-- Se /admin é liberado para 127.0.0.1 e a aplicação confia no header, o acesso é concedido.

X-Original-URL / X-Rewrite-URL

+

[Finalidade]: Headers não-padrão usados por proxies para informar a URL original solicitada.

[Vulnerabilidade]: Vetor clássico de SSRF. Se o backend busca um recurso com base neste header, um atacante pode forçar requisições para a rede interna, escanear portas ou interagir com APIs de metadados da nuvem.

[Payload: SSRF]:

GET / HTTP/1.1
Host: vulnerable-app.com
X-Original-URL: /api/internal-data?host=169.254.169.254

-- A aplicação pode tentar acessar a URL interna, vazando metadados de serviços em nuvem (como no IP de exemplo).

Referer

+

[Finalidade]: Indica a URL de origem da requisição. Usado para analytics e, às vezes, como uma fraca proteção anti-CSRF.

[Vulnerabilidade]: Vazamento de informações sensíveis. Se tokens de sessão ou de reset estão na URL, e a página requisita um recurso externo, o header `Referer` vaza a URL completa para um terceiro.

[Cenário de Vazamento]:

// 1. Usuário acessa: https://site.com/reset?token=SECRET_TOKEN
// 2. A página carrega um recurso: <img src="https://third-party.com/pixel.gif">
// 3. A requisição para a imagem envia o header:
   Referer: https://site.com/reset?token=SECRET_TOKEN

-- O `third-party.com` agora possui o token secreto.

[ Cenários de Impacto ]

Aqui conectamos a exploração ao resultado. Uma manipulação de header não é apenas uma falha técnica, é uma brecha com consequências reais. Veja como a exploração dos vetores anteriores se traduz em comprometimento do sistema.

💥 Bypass de Auth/Whitelist

Quando a aplicação usa X-Forwarded-For para identificar uma fonte confiável. Forjamos o header, o sistema nos vê como localhost e nos dá acesso root.

🌐 SSRF

Manipulando Host ou X-Original-URL, transformamos o servidor em nosso proxy pessoal para pivotar para a rede interna, exfiltrar dados da nuvem e mapear a infraestrutura.

☠️ Web Cache Poisoning

Injetamos uma resposta maliciosa no cache via headers não-cacheados (X-Forwarded-Host). O próximo usuário a solicitar o recurso recebe nosso payload. XSS para todos.

🔑 Password Reset Poisoning

Solicitamos um reset para a vítima, mas trocamos o Host para nosso domínio. O link de reset gerado aponta para nós. Quando a vítima clica, interceptamos o token. Game over.

💉 Injeção de SQL/XSS

Menos comum, mas viável. Se headers como User-Agent ou Referer são logados sem sanitização, abrem vetores para SQLi ou XSS em painéis de admin.

ℹ️ Reconnaissance

Headers de resposta como Server e X-Powered-By vazam a stack. É o primeiro passo para encontrar exploits específicos para versões vulneráveis.

[ Recomendações e Mitigações ]

Hora da defesa. A segurança em HTTP headers é um jogo de duas frentes: hardening do servidor e validação paranoica no código. Aqui estão as regras de firewall e as boas práticas de desenvolvimento para fechar as brechas.

🛡️ Headers de Segurança (Hardening)

  • Strict-Transport-Security (HSTS): Força HTTPS. Mata ataques de SSL stripping.
  • Content-Security-Policy (CSP): Whitelist de recursos. Defesa primária contra XSS.
  • X-Frame-Options: Bloqueia iframes. Neutraliza Clickjacking.
  • X-Content-Type-Options: nosniff: Impede que o browser "adivinhe" o MIME-type.
  • Referrer-Policy: Controla o vazamento de info via Referer.
  • Permissions-Policy: Controla o acesso a APIs do browser (câmera, mic, etc).

⚙️ Boas Práticas de Backend

  • Confiança Zero: Trate todo header como input malicioso. Valide e sanitize tudo.
  • Whitelist de Domínios: Use uma lista de domínios permitidos no código em vez de confiar no header `Host`.
  • Validação de IP: Configure o proxy para usar um header confiável e que não possa ser injetado pelo cliente.
  • Remova Headers Informativos: Omita `Server`, `X-Powered-By`, etc. Menos info, menos superfície de ataque.
  • Bloqueie SSRF: Não permita que a aplicação faça requisições para URLs controladas, mesmo que parcialmente, pelo usuário.