Host Header Injection
La Host Header Injection abusa de que muchas aplicaciones confían en la cabecera Host (o en X-Forwarded-Host) para decidir a qué dominio pertenece la petición y construir URLs absolutas. Como esa cabecera la controla el cliente, cambiarla permite desviar enlaces, correos y redirecciones hacia un dominio del atacante sin tocar la aplicación.
El vector más rentable es el envenenamiento del restablecimiento de contraseña: muchas webs generan el enlace de reset con el Host de la petición, así que si lo cambiamos, la víctima recibe un correo con un enlace que apunta a nuestro servidor y nos entrega su token al pulsarlo.
POST /reset-password HTTP/1.1
Host: atacante.tld
Content-Type: application/x-www-form-urlencoded
email=victima@empresa.comSi el back-end ignora Host pero honra X-Forwarded-Host, se prueba esa (y X-Host, X-Forwarded-Server). Otros impactos: acceso a vhosts internos o paneles restringidos cambiando el Host, y alimentar un envenenamiento de caché cuando el valor reflejado se cachea. Cuando el Host acaba en una petición del servidor, roza el SSRF.
Cómo detectarlo. La firma es una petición cuyo Host (o X-Forwarded-Host) no coincide con el dominio real del servicio, seguida de un correo o una respuesta que contiene ese dominio ajeno. En los logs, valores de Host que no están entre los virtual hosts válidos, y enlaces de restablecimiento generados con un dominio distinto al canónico. Un pico de peticiones a /reset con Host variable es sospechoso.
Defensa. Validar el Host contra una lista blanca de dominios permitidos y rechazar el resto; no usar Host/X-Forwarded-Host para construir URLs de correo (usar un dominio canónico fijo en configuración); e ignorar cabeceras X-Forwarded-* salvo que vengan de un proxy de confianza. Se apoya en CRLF injection cuando además se pueden inyectar cabeceras.