¿IIS y ASP son vulnerables a los mismos ataques de encabezado de host que hemos visto en Apache y Nginx? Específicamente los ataques que utilizan el encabezado de host HTTP para restablecer una contraseña o implementar el envenenamiento de caché web. Estos ataques específicos utilizan las variables SERVER y HOST.
Cualquier información o ayuda es muy apreciada.
El encabezado "HOST" es parte del protocolo http, las aplicaciones vulnerables son vulnerables porque insertan el valor de este encabezado en el código de la aplicación sin la validación adecuada, esto significa que no solo las aplicaciones alojadas en Apache / Nginx pueden ser vulnerables. En resumen, la respuesta es sí, su aplicación podría ser vulnerable independientemente del tipo de idioma / servidor que utilice. Evite extraer información de este encabezado, ya que manipularlo desde el lado del cliente es trivial.
Estoy de acuerdo con Kotzu, lo hubiera comentado, pero solo por poder publicar una captura de pantalla, estoy publicando esto como respuesta.
Respuesta corta:
Sí, los ataques de encabezado de host son posibles en la pila IIS y ASP.NET.
Iniciación de restablecimiento de contraseña:
Esto sucede si el código está mal escrito, en el sitio web cuando el usuario solicita un enlace para restablecer la contraseña, el sitio web envía un enlace con un token secreto a la dirección de correo electrónico de ese usuario.
Diga que el enlace es http (s): // [genuinesite] /resetpassword.aspx?someguid Y guid sería la clave para un registro en la base de datos que sabe a quién reiniciar la contraseña.
Pero si el código se escribió mal para crear ese enlace, usaría Protocol + Host Header + "/resetpasswordword.aspx?" + guid,
luego el atacante puede pasar fácilmente el encabezado del host a su propio sitio web,
Así que el sitio genuino generará y enviará un correo electrónico con un enlace como http (s): // [jenuinesite] /resetpassword.aspx?someguid
y el atacante tendría ese sitio allí,
y podría obtener los parámetros de la cadena de consulta y restablecer la contraseña en nombre del usuario, siempre que el usuario haga clic en el enlace del correo electrónico. Y generalmente lo hacen porque el correo electrónico es realmente enviado por genuinesite.
Muchos componentes de software populares tienen esta vulnerabilidad.
Intoxicación de caché:
El caché también puede ser envenenado por HTTP Response Splinting, que nuevamente no es común hoy en día, pero aquí estamos hablando de Host Header.
Los cachés ahora son días de host, por lo que con Host Header, si alguien intenta envenenar el caché, se mantendrá separado del caché de genuinesite.
Básicamente, al generar (renderizar) html, en el código, si en algún lugar hay un código deficiente donde se genera html / javascript basado en HOST, podría ser vulnerable. Siempre que haya algún tipo de servidor o almacenamiento en caché de proxy del html representado.
Digamos que el código está generando html como Home luego, al manipular el encabezado del host, puedes hacerlo como Home
Y esa página sería del lado del servidor en caché, y el atacante puede robar cookies de todos los usuarios a los que se sirve esa página en caché.
Obviamente, el atacante usará Pragma: no-cache para eliminar primero la página realmente almacenada en caché y luego posicionar el caché con la versión manipulada del encabezado del host.
Pero como dije, en ASP.NET e IIS world no he visto mucho Cache Poisoning with Host Header, pero nunca sabemos que la gente escriba código pobre todo el tiempo.
¿Cómo podemos evitar esto?
Creo que la forma más fácil (y una de las mejores prácticas) es tener la configuración de enlace adecuada en su IIS, incluso si está hospedando solo un sitio web con su IIS.
Incluso puede tener varios nombres de host permitidos para un sitio web.
De esta manera, si alguien cambia el encabezado del host, ni siquiera llegará a su sitio web en IIS.
Lea otras preguntas en las etiquetas web-application web-browser attack-prevention asp.net iis