Host header injection

Muchas apps usan la cabecera Host (o X-Forwarded-Host) para construir URLs absolutas: enlaces de correo, recursos, redirecciones, canónicos. Si confían en ella sin validar, el atacante la manipula para envenenar enlaces de recuperación de contraseña, la caché, provocar SSRF o acceder a vhosts internos. El valor de Host lo pone el cliente, así que es entrada no confiable.

Modelo de amenaza

Password reset poisoning: el enlace de reset apunta al dominio del atacante → la víctima hace clic → el token se filtra en el Referer/petición al dominio atacante → ATO.
Web cache poisoning (si el Host/X-Forwarded-Host entra en la respuesta cacheada; ver ficha de cache).
SSRF / routing: alcanzar vhosts internos o paneles por nombre.
Fuga de información y evasión de controles basados en host.

Anatomía

El servidor genera, por ejemplo, el enlace de reset con https://<Host>/reset?token=.... Si cambias el Host (o añades X-Forwarded-Host, X-Host, X-Forwarded-Server), el correo que recibe la víctima apunta a tu servidor. Variantes de inyección:

Cambiar directamente Host:.
Añadir X-Forwarded-Host: evil.tld (muchos frameworks lo priorizan).
Doble Host o Host: victima.tld:@evil.tld según el parser.
Dangling markup vía Host cuando se refleja en la página.

Red Team

# Password reset poisoning
POST /forgot-password HTTP/1.1
Host: evil.tld
# o manteniendo el Host real pero añadiendo:
X-Forwarded-Host: evil.tld
-> el email de la víctima enlaza a https://evil.tld/reset?token=TOKEN_DE_LA_VICTIMA

# Comprobar reflejo (cache poisoning / XSS)
GET / HTTP/1.1
Host: evil.tld           # ¿aparece "evil.tld" en la respuesta (scripts, enlaces)?

# Acceso a vhost interno
Host: internal-admin      # ¿enruta a un panel interno?

Confirma el impacto comprobando si el correo/recurso usa el host inyectado.

Herramientas

Burp Suite (modificar Host/X-Forwarded-Host en Repeater), Param Miner para cabeceras no clave.

Blue Team

Detección

Peticiones con Host/X-Forwarded-Host que no coinciden con los dominios esperados; enlaces de reset hacia dominios externos; cabeceras Host duplicadas.

Hardening

No construir URLs con el Host de la petición. Usar un dominio canónico configurado en el servidor/app.
Lista blanca de hosts válidos; rechazar (400) peticiones con Host inesperado.
Ignorar X-Forwarded-Host salvo que venga de un proxy de confianza controlado.
Para el reset, generar el enlace con el dominio canónico, nunca con el Host recibido.

Respuesta

Invalidar tokens de reset potencialmente filtrados, corregir la generación de enlaces, y revisar cachés envenenadas.

CVEs y casos reales

El password reset poisoning vía host header ha afectado a múltiples frameworks y apps (incluidos CMS populares y aplicaciones a medida); es un clásico de bug bounty con impacto ATO por el robo del token de reset.
Varias plataformas han sufrido cache poisoning a través de X-Forwarded-Host.

CVEs/incidentes en NVD (https://nvd.nist.gov/vuln/search) y GitHub Advisories (https://github.com/advisories).

Checklist de prueba

Probado cambiar Host y añadir X-Forwarded-Host/X-Host en el reset.
Confirmado si el enlace del correo usa el host inyectado.
Probado reflejo del Host en la respuesta (cache/XSS).
Evaluado acceso a vhosts internos / routing.