asp.net security http url asp.net-4.0

asp.net - ¿Por qué usar una URL que contiene dos puntos es considerada como una "solicitud potencialmente peligrosa"?



security http (3)

Alguien (probablemente un bot) envió una solicitud con la siguiente URL a mi aplicación de formularios web ASP.NET 4.0 (que se ejecuta en IIS 7.0):

http://ipaddress-of-my-applications-domain/bla1.bla2.bla3.bla4.bla5:)

Esto causó una System.Web.HttpException . Recibí un correo electrónico de registro de ASP.NET HealthMonitoring que había configurado y me dijo:

Se detectó un valor Request.Path potencialmente peligroso del cliente (:).

La traza de la pila era:

System.Web.HttpRequest.ValidateInputIfRequiredByConfig() System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)

¿Por qué los dos puntos en la URL son "potencialmente peligrosos"? ¿Qué cosas peligrosas se pueden hacer con esa URL? ¿Tengo algún agujero de seguridad aquí que no conozco?

Gracias por la explicación por adelantado!

Editar

He probado que un signo de dos puntos en una cadena de consulta (como http://mydomain.com?Test=9:) ) no causa esta excepción.

En NTFS, una ruta de archivo determinada puede tener múltiples flujos de datos asociados. Aparte de la transmisión principal, también conocida como $DATA , puede haber otras, que se utilizan normalmente para almacenar metadatos como el marcador de la zona de Internet en los archivos descargados.

Se accede a los flujos de datos alternativos utilizando un separador de dos puntos, por ejemplo. file.dat:$DATA es una forma alternativa de decir file.dat . La presencia de ADS a través de la web ha causado a Microsoft algunos problemas de seguridad en el pasado (por ejemplo, devolver el código fuente de las páginas ASP en lugar de ejecutarlas), por lo que, como precaución, están bloqueando el uso de dos puntos en la parte de la ruta URL, ya que la parte de la ruta a menudo se asigna al sistema de archivos (aunque no en su caso). Esto es menos probable que ocurra a partir de la cadena de consulta, por lo que no se bloquea allí.

Esto está lejos de ser el peor falso positivo que generará la Validación. Sus características anti-inyección son mucho peores. Personalmente, siempre lo deshabilitaría, ya que es una característica estúpida que nunca puede hacer que tu aplicación web sea segura; solo la atención adecuada al escape de cuerdas (y el saneamiento intenso de cualquier cosa que planee usar como nombre de archivo) puede hacer eso.

Hay otros caracteres que, incluso si desactivas la Validación de la solicitud, no puedes poner una parte de la ruta con fines de enrutamiento. En particular, las barras diagonales ( %2F , %5C , y las secuencias de bytes que serían secuencias no válidas de UTF-8 que se resuelven en el mismo) y el byte cero. Es mejor ser conservador acerca de lo que usted pone en los caminos en general.

No recuerdo exactamente, pero Internet Explorer está ligado al sistema operativo y fue capaz de realizar algunas cosas malas, como "con: sss", fue capaz de abrir la consola y ejecutar algunos comandos por lotes, etc., todo antes de que se consideren dos puntos como protocolo y Windows lo permite Usted puede anular / crear nuevos protocolos que su dll pueda abrir y consumir. Cualquier persona con mayor experiencia en com monikers url y ur puede darle una respuesta muy correcta.