Obtén todo lo que necesitas de una CDN moderna: desde una escala sin esfuerzo y seguridad integrada hasta control programable y visibilidad total.
¿Qué son los ataques de encabezado de host HTTP?
Los ataques de encabezado Host de HTTP se han convertido en una técnica común para los atacantes y tienen varias variantes. Antes de profundizar en los ataques y en lo que permiten, comencemos por explicar qué es un encabezado Host de HTTP.
¿Qué es el encabezado HTTP Host?
El encabezado HTTP Host proporciona información sobre el host y el puerto, y está diseñado para ayudar al servidor de origen a determinar qué recursos usar cuando atiende solicitudes para múltiples dominios.
Otros encabezados de Host
A veces, las aplicaciones complementan el encabezado Host con encabezados adicionales similares a Host, como “X-Forwarded-Host”, “X-Host” y otras variaciones. Usaremos estos en algunas de las descripciones de ataques a continuación, ya que son vulnerables de la misma manera que el encabezado Host si se usan de forma incorrecta.
Los tipos de ataques de encabezado HTTP Host
El encabezado Host es una parte fundamental del uso de internet, pero las aplicaciones se exponen a vulnerabilidades cuando se confía implícitamente en el encabezado Host, se usa para funcionalidad adicional o está mal configurado. Los atacantes pueden explotar este comportamiento al inyectar diferentes tipos de contenido en el encabezado Host, lo que puede provocar vulnerabilidades más graves, entre ellas:
Envenenamiento de encabezado de host
Envenenamiento de caché web
Envenenamiento de restablecimiento de contraseña
Falsificación de solicitudes del lado del servidor
Dependiendo de cómo una aplicación use los valores proporcionados por el encabezado Host, también podría permitir otros ataques, como Cross-Site Scripting o inyección SQL, igual que cualquier otra entrada proporcionada por el usuario cuando no se procesa de forma segura. Por ahora, supongamos que no usas el encabezado Host en consultas SQL sin procesar y abordemos los ataques más directos.
1. Envenenamiento del encabezado de host
En los casos más simples, una aplicación puede usar el valor del encabezado Host para redirigir el tráfico, por ejemplo, a la página de inicio de sesión de la aplicación. Si la aplicación usa el encabezado Host para construir el enlace de redirección, un atacante puede enviar la siguiente solicitud HTTP:
GET / HTTP/1.1
Host: www.attackers-domain.example.com
Y generar una respuesta redirigiendo a su dominio controlado:
HTTP/1.1 302 Found
...
Location: http://www.attackers-domain.example.com/login.php
Por sí solo, este ataque no es muy útil, ya que es difícil lograr que un usuario objetivo haga esta solicitud. Sin embargo, el envenenamiento de encabezados Host puede combinarse con otros ataques para aumentar su eficacia.
2. Envenenamiento de caché web
Web Cache Poisoning no es una vulnerabilidad del encabezado Host en sí, sino un mecanismo de distribución que hace explotable el Host Header Poisoning mencionado anteriormente. Supongamos que una aplicación no usa el encabezado Host para construir sus enlaces de redirección (¡bien!), sino que usa un encabezado alternativo como X-Host para construirlos (¡mal!). En este escenario, un atacante puede inyectar su dominio en X-Host para envenenar la redirección; sin embargo, aún necesita una forma de entregar esa redirección a los usuarios.
Aquí es donde entra en juego el envenenamiento de caché web. La caché web suele usar partes de una solicitud HTTP como “claves” para saber cuándo usar contenido de caché en lugar de enviar la solicitud al origen. Esta clave suele incluir el encabezado Host y puede incluir cualquier otro encabezado. En nuestro ejemplo, si X-Host no forma parte de la clave de caché pero se usa de forma insegura en la respuesta (como en nuestro ejemplo de redirigir), los atacante pueden usar la caché para entregar a otros usuario su redirección maliciosa. Luego, el atacante encuentra una forma de hacer que su solicitud se almacene en caché para servirla a otros usuario.
Echemos un vistazo a un ejemplo de envenenamiento de caché web. Primero, el atacante consigue que se almacene en caché la siguiente solicitud, que incluye su dominio malicioso en el encabezado X-Host, que se usará en una redirección:
GET / HTTP/1.1
Host: www.super-cool-fun-domain.example.com
X-Host: www.attackers-domain.example.com
Luego, un usuario benigno decide visitar la aplicación y envía una solicitud normal:
GET / HTTP/1.1
Host: www.super-cool-fun-domain.example.com
X-Host: www.super-cool-fun-domain.example.com
Suponiendo que la solicitud del atacante se almacenó en caché según la ruta y el encabezado Host, el usuario legítimo ahora recibe la respuesta en caché envenenada, que lo redirige a la página del atacante:
HTTP/1.1 302 Found
...
Location: http://www.attackers-domain.example.com/login.php
Los ataques de envenenamiento de caché web dependen de la discrepancia entre los encabezados que se usan como clave de caché y los encabezados que usa la aplicación para formular respuestas. En el ejemplo anterior, el encabezado X-Host proporcionó una forma de envenenar las respuestas en caché, redirigiendo a los usuarios a un sitio malicioso en lugar de a la aplicación real.
3. Envenenamiento del restablecimiento de contraseña
Password Reset Poisoning es muy similar a nuestro anterior Host Header Poisoning, ya que la aplicación vulnerable usa el encabezado Host para construir el enlace de restablecimiento de contraseña que envía al usuario solicitado durante el flujo de trabajo de restablecimiento. Por ejemplo, supongamos que un atacante envía la siguiente solicitud POST para solicitar un restablecimiento de contraseña para el usuario “alice”:
POST /password-reset HTTP/1.1
Host: www.attackers-domain.example.com
...
usuario=alice
La aplicación usa el valor del encabezado Host para construir el enlace de restablecimiento y envía un correo electrónico al usuario alice con el enlace:
www.attackers-domain.example.com?reset_token=super-random-reset-token-value-12345
Si el usuario hace clic en el enlace, el atacante captura el token de restablecimiento y puede restablecer la contraseña del usuario con un valor propio.
4. Falsificación de solicitudes del lado del servidor
La falsificación de solicitudes del lado del servidor (SSRF) es una vulnerabilidad que permite que un atacante haga que la aplicación del lado del servidor realice solicitudes a una ubicación arbitraria. En un SSRF de encabezado Host, el atacante está explotando el enrutamiento que usan los sistemas ubicados entre el usuario y la aplicación del lado del servidor. Si este middleware (por ejemplo, un balanceo de carga) es vulnerable a SSRF del encabezado Host, el atacante posiblemente pueda usar esto para interactuar con sistemas internos a los que de otro modo no tendría acceso. Una forma común de probar esto es colocar un dominio único y controlado (por ejemplo, Burp Collaborator de Portswigger o interactsh de ProjectDiscovery) en el valor del encabezado Host. Si ese dominio único recibe una búsqueda de DNS u otra solicitud de un sistema en la ruta de red de las aplicaciones objetivo (por ejemplo, el balanceo de carga) durante un ataque de encabezado Host, entonces puede ser vulnerable a SSRF. Estos ataques tienden a ser complejos en la práctica, pero también devastadores, como se demuestra ampliamente en la investigación de James Kettle.
Ejemplos reales de ataques de encabezado Host de HTTP
Ahora que entiendes los tipos de ataques de encabezado Host, veamos algunos ejemplos del mundo real.
CVE-2022-29933: envenenamiento de restablecimiento de contraseña en Craft CMS
SEC Consult descubrió que la instalación predeterminada de Craft CMS construye correos electrónicos de restablecimiento de contraseña usando el valor del encabezado HTTP “X-Forwarded-Host”. En este ejemplo, un atacante inyecta el dominio que controla en X-Forwarded-Host para envenenar el enlace de restablecimiento de contraseña para el usuario alice de la siguiente manera:
POST /index.php?p=admin/actions/users/send-password-reset-email HTTP/1.1
Host: <installation-domain>
X-Forwarded-Host: www.attackers-domain.example.com
...
cookie: CRAFT_CSRF_TOKEN=[...]
loginName=alice@example.com
Cuando el usuario alice@example.com recibe el correo electrónico para restablecer la contraseña, este contiene un enlace al dominio controlado por el atacante:
http://www.attackers-domain.example.com/index.php?p=admin/set-password&code=<reset-code>&id=<uuid>
Si el usuario sigue el enlace, el atacante ya habrá capturado su código de restablecimiento y podrá restablecer su contraseña para tomar el control de la cuenta.
SSRF ciego en Slack mediante inyección de X-Forwarded-Host
Este ataque omite una validación débil de X-Forwarded-Host para lograr SSRF ciego en files.slack.com. Primero, files.slack.com intenta validar el encabezado Host y el encabezado X-Forwarded-Host durante el procesamiento, y devuelve un código de respuesta HTTP 500 cuando no son files.slack.com. Sin embargo, la validación de X-Forwarded-Host puede omitirse agregando un carácter @ al final del dominio. Entonces, el atacante configura un dominio de callback para capturar solicitudes (por ejemplo, con Burp Collaborator, interactsh de ProjectDiscovery) y envía la siguiente solicitud a slack.files.com:
GET /<URI> HTTP/1.1
Host: files.slack.com
...
X-Forwarded-Host: files.slack.com@www.unique-attackers-domain.example.com
El files.slack.com en la URL construida a partir del encabezado X-Forwarded-Host se trata como el usuario HTTP (HTTP BasicAuth), y www.unique-attackers-domain.example.com se trata como el nombre de host. El atacante recibe una solicitud de un sistema backend, lo que confirma el SSRF exitoso. A partir de aquí, se pueden usar diferentes técnicas de SSRF ciego para intentar filtrar información, interactuar con sistemas backend y más.
Cómo prevenir ataques de encabezado HTTP Host
Hay varias formas de prevenir ataques de encabezado Host de HTTP que varían en su eficacia y desventajas. A continuación, encontrarás soluciones prácticas para prevenir este tipo de ataque.
Evita usar el valor del encabezado Host y sus variantes en el código de la aplicación
La forma más sencilla de prevenir ataques de encabezado Host es evitar usar el valor del encabezado Host en el código de la aplicación. Además, usar configuraciones del servidor o URL relativas en su lugar frustrará por completo los ataques de encabezado Host.
Realiza una validación estricta de los valores del encabezado Host
Si tienes que usar el valor del encabezado Host, se deben usar las siguientes técnicas para prevenir ataques de encabezado Host:
Valida que el encabezado Host esté en una lista permitida de valores. Por ejemplo, si tu aplicación solo usa tres dominios, asegúrate de que el encabezado Host sea solo uno de esos tres valores.
Valida que solo haya un encabezado Host. En ocasiones, los encabezados Host duplicados pueden usarse para omitir la validación si la validación y el uso del encabezado terminan extrayendo valores diferentes de la solicitud.
Evita usar alternativas y anulaciones del encabezado Host, como X-Host o X-Forwarded-Host, y si tienes que hacerlo, sigue las mismas recomendaciones proporcionadas para el encabezado Host.
Cómo Fastly ayuda a prevenir ataques de encabezado Host de HTTP
Sigue la guía de Fastly para prevenir el envenenamiento de caché y asegurarte de que haya protecciones adicionales implementadas.
Si usas el firewall de aplicación web de próxima generación de Fastly, puedes agregar protecciones adicionales para defenderte de ataques de encabezado Host de HTTP y bloquear todas las solicitudes con encabezados Host no válidos (por ejemplo, los que no están en tu lista permitida de dominios).
Resumen
El encabezado Host es una parte vital de internet (y de Fastly), pero cuando se confía implícitamente en el encabezado Host, se usa para funcionalidad adicional o está mal configurado, los atacante pueden explotar este comportamiento inyectando diferentes tipos de contenido malicioso en él. Esto puede permitir múltiples tipos de ataques, incluidos el envenenamiento del encabezado de host, el envenenamiento de caché web, el envenenamiento del restablecimiento de contraseña y la falsificación de solicitudes del lado del servidor (SSRF). Con las soluciones que hemos descrito, combinadas con la guía de Fastly para prevenir el envenenamiento de caché, las aplicaciones pueden prevenir variantes de ataques de encabezado de host.