Explotando la función de redireccionamiento HTTP a través del encabezado del Host

Esta es una pregunta antigua, pero para completar, agregaré algunas ideas.

La referencia en el término del ataque de encabezados de host es Ataques de encabezado de host prácticos (2013) ) y sigue siendo válido.

Los atacantes seguramente utilizarían el truco de uri absoluto para inyectar el encabezado incorrecto y asegurarse de que llegan al host virtual correcto. Pero en algunos casos esto es ni siquiera requerido (como quizás en su aplicación actual, donde se acepta cualquier solicitud con cualquier encabezado de Host, dado que la consulta HTTP se realiza en la IP correcta)

# instead of
  GET /uri HTTP/1.1
  Host: good.name.com
# they would use
  GET http://good.name.com/uri HTTP/1.1
  Host: evil.com

Y esto podría explotarse principalmente de 3 maneras (principalmente, pero eso está abierto a más ideas):

• envenenamiento de caché : si su aplicación alimenta la página con un dominio tomado de la solicitud (al reconstruir las URL absolutas en enlaces html), es posible que estos dominios incorrectos terminen en la versión en caché de la página para %código%. Bastante difícil de realizar (el caché puede terminar almacenando en caché la página como /uri y no http://good.name.com/uri .
• enlaces incorrectos en el correo electrónico : diga que su aplicación está enviando un enlace de restablecimiento de contraseña una vez, con la url tomada del encabezado del host, luego el atacante podría esperar que alguien haga clic en el enlace con el dominio evil.com . Pero significa que alguien hace clic en un enlace de correo electrónico para restablecer la contraseña sin pedir un restablecimiento de la contraseña (ya que el atacante realizó la consulta incorrecta)
• Inyección de CRLF , al igual que con todos los encabezados inyectados, un objetivo podría ser obtener una respuesta donde una entrada de host muy mala (que contenga /uri o CRLF , que sea "\ r \ n") ser reutilizado sin filtrar en los encabezados de respuesta. Esto lleva a la inyección de encabezados en la respuesta.

Como @Steffen Ullrich señaló que no hay manera de llevar a un usuario inocente a realizar el ataque (especialmente porque el navegador usa la resolución DNS del nombre del host para encontrar la IP del servidor web). Así que la única víctima parece ser el atacante . Pero de todos modos, el objetivo de ataque es asíncrono. No es como un ataque xss, el objetivo no es el usuario que recibe la respuesta. En el posicionamiento de la memoria caché es bastante obvio (el objetivo es la memoria caché), en el correo electrónico de restablecimiento de contraseña se usa para llevar el ataque a la víctima, y en la inyección CRLF ingresamos a la división de respuesta HTTP y contrabando de HTTP zona, donde las consecuencias son bastante difíciles, pero pueden provocar envenenamiento de caché, denegación de servicio, envenenamiento de socket, solicitudes incompletas, etc. El objetivo es un proxy inverso, y el ataque se expandirá posteriormente a otros usuarios a través de este apoderado.

No puede enviar un encabezado de host personalizado desde el navegador, lo que significa que no puede explotar esto utilizando solo un navegador. Y, dado que se usa HTTPS, no puede montar un hombre en el ataque central para modificar el encabezado del Host de una solicitud existente. Pero incluso si no se utilizaría HTTPS, no obtendría nada nuevo al modificar el encabezado del Host en la solicitud, ya que como hombre en el medio ya podría modificar el encabezado de la Ubicación en la respuesta de todos modos.

En resumen, dudo que el problema que hayas encontrado pueda usarse para cualquier cosa maliciosa, al menos no cuando uses el navegador como cliente.