Hacer que SERVER_NAME sea confiable en IIS

Question

Hacer que SERVER_NAME sea confiable en IIS

#1 de user2320464 (1 votos)
#2 de md_1976 (0 votos)
#3 de Richard Metzler (0 votos)

1

Estoy tratando de corregir la vulnerabilidad de un encabezado de host desde el lado del servidor tanto como sea posible. La vulnerabilidad es un ataque de encabezado de host HTTP. Lo que me gustaría hacer es permitir que solo se pasen encabezados de host válidos a través de aplicaciones en ejecución. De esta manera, un encabezado de host que debería ser example.com no se pasa como evil.com . Hay una explicación decente de esta vulnerabilidad aquí: enlace .

Creo que la Reescritura de URL podría ayudar con esto, pero no tengo mucha experiencia con eso, así que no estoy seguro. ¿Alguien ha endurecido sus servidores contra este ataque?

El servidor está configurado con enlaces de encabezado para dominios permitidos, aunque esto no detendrá una solicitud que contenga un valor de encabezado de host diferente.

Si encuentro una forma de filtrar, detecto que el encabezado del host es incorrecto, ¿qué tipo de respuesta debería devolverse?

vulnerability iis

pregunta Brettski 05.06.2015 - 18:17

fuente

3 respuestas

Lea otras preguntas en las etiquetas vulnerability iis

Múltiples cuentas bancarias en una pasarela de pago o cuenta mercantil ¿Adición de sal en el hashing? [duplicar]

score 1 · Answer 1

En resumen, no utilice enlaces comodín.

Solo vincule los nombres de host aplicables a los sitios web y sea específico. Por ejemplo, solo permitir www.website.com solo permitirá solicitudes con ese valor de encabezado de host. El sitio web no procesará a los demás, por lo que es prácticamente una lista blanca de nombres de host aceptables.

Al adoptar el enfoque de reescritura de URL (o similar), se debe agregar una nueva regla para cada solicitud "incorrecta". Este no es un buen modelo de soporte (es decir, whack-a-mole) ya que no hay forma de mantenerse al día con las posibles combinaciones. Como ejemplo, podría registrar mysite.foo en su IP y ahora necesita agregar una regla. Al adoptar el enfoque recomendado y no utilizar enlaces comodín, la solicitud ni siquiera irá a IIS, ya que no hay un sitio web configurado para procesar la solicitud.

La vulnerabilidad mencionada proviene de sitios web que están configurados para aceptar cualquier nombre de host. Al hacerlo, permite que ese valor rellene la variable que ya no es confiable como podría ser cualquier cosa. Al adoptar el enfoque de solo vincular nombres de host específicos, se asegura de que solo esos valores llenarán la variable y, por lo tanto, serán confiables.

score 0 · Answer 2

Para responder a su pregunta original, sí, la Reescritura de URL puede lograr esto con IIS. La reescritura de URL básicamente crea entradas en el archivo web.config en /wwwroot/web.config (o lo crea si no existe).

El web.config puede manipularse manualmente para agregar las reglas de inyección del host, pero IIS no sabrá cómo leer el web.config a menos que se haya instalado la Reescritura de URL. El sitio web no podrá comenzar. Por lo tanto, la Reescritura de URL debe instalarse incluso si desea utilizar un script o un proceso manual para actualizar su (s) servidor (es).

Las siguientes reglas indican el encabezado HTTP_HOST si no es "10.141.13.170" y no es "253.23.65.155" y no es "website.com", luego cancele la solicitud. Las múltiples entradas le permiten acomodar una IP interna, una IP externa y un nombre de dominio, por ejemplo.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="Host_Injection_Prevention_Rule_1" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
          <match url="*" />
          <conditions>
            <add input="{HTTP_HOST}" pattern="10.141.13.170" negate="true" />
            <add input="{HTTP_HOST}" pattern="253.23.65.155" negate="true" />
            <add input="{HTTP_HOST}" pattern="website.com" negate="true" />
          </conditions>
          <action type="AbortRequest" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

score 0 · Answer 3

Su pregunta es de 2015, pero en 2018 Microsoft lanzó un aviso de seguridad [0] [1] que indica el mismo problema que sospechaba que tenía. Para citar del aviso:

Por ejemplo, si IIS está configurado para responder a las solicitudes de hosts contoso.com o * .contoso.com, la aplicación está protegida.

Si IIS está configurado para responder a cualquier solicitud de cualquier host, la aplicación es vulnerable.

[...]

Software afectado

Cualquier aplicación alojada en ASP.NET Core que esté directamente expuesta a Internet, o alojada detrás de un proxy que no valide ni restrinja los encabezados de host a valores conocidos.

[0] enlace
[1] enlace