Manejar adecuadamente la solicitud de IIS con el signo de porcentaje en la URL (/%)

14

Estoy buscando cualquier tipo de solución para obtener correctamente una solicitud de IIS como /programming//% y http://bing.com/% para no mostrar una página 400 Bad Request, pero mostrar una página de error personalizada similar a como http://google.com/% y http://facebook.com/% lo hacen (obviamente, esos ejemplos no están en IIS).

Creo que he intentado establecer todas las configuraciones de registro http.sys aplicables (AllowRestrictedChars, PercentUAllowed) según http://support.microsoft.com/kb/820129 pero eso no ha ayudado. La configuración de AllowRestrictedChars y una página 400 personalizada tiene URL fijas como /programming//%12 pero no /%.

iis iis-7 iis-7.5

— bkaid
fuente

3

¿Te das cuenta de que es un escape de URL incompleto y es una mala solicitud, por lo que 400 lo maneja correctamente? PercentU y AllowRestricted no son realmente aplicables

— Rup

Sí, lo hago (y /% es solo una URL de ejemplo, pero obviamente el error ocurre con cada carácter de escape no válido). IIS está manejando el 400, pero quiero mostrar una página personalizada 400 como puedo con otros códigos de estado en IIS, y al igual que la forma no puede servidores IIS de 400.

— bkaid

Tengo algunos enlaces poderosos que apuntan a mis sitios web que están codificados por error de esta manera. pero no se me permite 301 a la página correcta, en cambio es un error difícil. Esto es inaceptable.

— boomhauer

20

Esto está bloqueado justo en el nivel del kernel IIS. Como prueba, saqué todos los módulos en IIS para que ni siquiera tuviera un controlador de página estático, y todavía mostraba el mensaje de error 400.

No creo que sea posible con IIS evitar eso. La configuración de registro que mencionó es para otros tipos de caracteres restringidos. No he visto una palanca para cambiar esa funcionalidad.

¿Cuál es tu objetivo es evitar eso? Abre más la superficie de ataque, y no puedo imaginar que un visitante legítimo se pierda como resultado de bloquear secuencias de escape de URL incompletas.

Actualización2: Aquí hay tres excelentes enlaces sobre esto. Tanto Nazim Lala como Wade Hilmo del equipo de IIS han blogueado sobre esto debido a la discusión sobre su pregunta. También Scott Hanselman tiene una excelente publicación sobre la parte de la cadena de consulta dentro de .NET:

Uso de caracteres especiales en IIS - Nazim Lala
Cómo IIS bloquea los caracteres en las URL - Wade Hilmo
Experimentos en Wackiness - Scott Hanselman

Actualización: Verifiqué con un miembro del equipo de IIS para obtener una respuesta autorizada. Mencionó que el% se considera un carácter inseguro según RFC 1738 ( http://www.ietf.org/rfc/rfc1738.txt ).

Aquí está el texto relevante:

Inseguro:

Los personajes pueden ser inseguros por varias razones. El carácter de espacio no es seguro porque pueden desaparecer espacios significativos y pueden introducirse espacios insignificantes cuando las URL se transcriben o se componen o se someten al tratamiento de programas de procesamiento de texto. Los caracteres "<" y ">" no son seguros porque se usan como delimitadores alrededor de las URL en texto libre; la comilla ("" ") se usa para delimitar URL en algunos sistemas. El carácter" # "no es seguro y siempre debe codificarse porque se usa en la World Wide Web y en otros sistemas para delimitar una URL de un fragmento / ancla identificador que podría seguirlo. El carácter "%" no es seguro porque se usa para codificaciones de otros caracteres. Otros caracteres no son seguros porque se sabe que las puertas de enlace y otros agentes de transporte a veces modifican dichos caracteres. Estos caracteres son "{", "}", "|", "\", "^", "~", "[", "]" y "` ".

Todos los caracteres inseguros siempre deben estar codificados dentro de una URL. Por ejemplo, el carácter "#" debe codificarse dentro de las URL, incluso en sistemas que normalmente no manejan identificadores de fragmentos o de anclaje, de modo que si la URL se copia en otro sistema que los usa, no será necesario cambiar el Codificación de URL.

Entonces, IIS bloquea esto proactivamente en el nivel central, una medida de seguridad proactiva para minimizar su superficie de ataque.

— Scott Forsyth - MVP
fuente

Prefiero registrar y manejar correctamente todos los errores para monitorear cualquier combinación extraña no válida de URL inválidas que se generan dinámicamente en mi sitio, en caso de que no se escape correctamente una URL.

— bkaid

1

Hay algo que decir para manejar los errores usted mismo, pero si las fallas evidentemente obvias se manejan por usted, es una buena ventaja. IIS no debe permitir caracteres que no correspondan a un archivo o carpeta en el sistema de archivos NTFS. No sabría qué hacer con la ruta de la carpeta. Si no es un patrón de caracteres que equivale a un carácter válido, entonces necesitaría tomar una decisión sobre qué hacer. En este caso, parece que se dedicó a bloquear en lugar de ignorar los caracteres no válidos.

— Scott Forsyth - MVP

@thekaido Como dijo Scott, no tiene sentido analizar URLS incompletas. ¿Qué tipo de página de error personalizado puede hacer ya que no tiene idea de lo que el usuario estaba tratando de hacer (ya que la solicitud está incompleta) Tenga en cuenta que IE9 ni siquiera le permitirá acceder al servidor con una solicitud incompleta

— Jim B

Entiendo las implicaciones de todas estas cosas, pero Apache y otros servidores web lo permiten al igual que IIS. Las URL con escape incorrecto son las únicas URL que IIS no le permitirá manejar, que yo sepa. IIS debe permitir y permite otros caracteres que no se asignan al sistema de archivos NTFS porque mi sitio está construido con ASP.NET MVC, donde las solicitudes se enrutarán a recursos que no estén basados en archivos.

— bkaid

En realidad estoy corregido sobre el% en NTFS. Está permitido, junto con la mayoría de los otros personajes: en.wikipedia.org/wiki/Ntfs . (busque los caracteres permitidos en los nombres de archivo).

— Scott Forsyth - MVP

3

Puedo pensar en 3 formas posibles

Cambie IIS para que apunte a una página personalizada por 400 errores de lo que normalmente hace
Si esto es exclusivo de un sitio web específico en IIS, puede hacer algo como esto en web.config:

<customErrors defaultRedirect = "ErrorPage.aspx" mode = "On">
<error statusCode = "400" redirect = "myCustom400Error.aspx" />
</customErrors>
Escriba un httpModule que inspeccione las URL entrantes y las maneje

— Dave Wise
fuente

44

Ninguno de estos trabajos: IIS nunca pasa la solicitud.

— bkaid

La opción n. ° 1 debería funcionar sin importar qué, porque así es como IIS responde al error

— Dave Wise

44

Acabo de probar la opción 1 y # 2 nuevamente y ninguno de ellos funciona. IIS está manejando esta solicitud especialmente como Scott menciona.

— bkaid

3

La única forma de evitar esto suena como verificar la URL antes de que el kernel de IIS pueda.

Debería enviar sus enlaces generados dinámicamente a través de un script para verificarlos antes de reenviar a su usuario final a esa URL ...

Salvo eso, usted sabe que esta es la única situación en la que IIS no lo manejará de la manera que desee. Entonces, por proceso de eliminación, si tiene una solicitud no manejada, sabe qué la causó.

¿Quizás verificar la referencia en una página 400 personalizada ayudaría a reducir la fuente del tráfico?

— Garrett
fuente

2

Esta publicación en el foro de IIS indica que HTTP 400 (Solicitud incorrecta) está bloqueada por http.sys y no llega a IIS, que coincide con los enlaces que @Scott Forsyth - MVP incluyó en su respuesta original.

Puede ver un registro de estas solicitudes en c: \ Windows \ System32 \ LogFiles \ HTTPERR \

No sé si puede configurar la página de respuesta que se envía al usuario para este tipo de error, pero dado que incluso Bing sufre de este problema, sospecho que eso no es posible o requeriría algunos ataques horribles del sistema.

— Héctor Correa
fuente