usado - ¿Para qué se utiliza el verbo HTTP no estándar "DEBUG" en ASP.NET/IIS?
iis 8.5 detailed error 405.0 method not allowed (3)
http://support.microsoft.com/kb/937523
Cuando el cliente intenta conectar automáticamente el depurador en una aplicación ASP.NET 2.0, el cliente envía una solicitud HTTP que contiene el verbo DEPURAR. Esta solicitud HTTP se utiliza para verificar que el proceso de la aplicación se está ejecutando y para seleccionar el proceso correcto para adjuntar.
Utiliza la autenticación de Windows y DCOM para hacer la depuración, así que no estoy al tanto de que el verbo DEBUG sea un gran riesgo de seguridad (obviamente, si estás permitiendo el tráfico RPC, entonces tienes problemas mayores) o de cualquier exploits. UrlScan sí lo bloquea por defecto, sin embargo.
Probablemente pondría un detector de red para verificar qué información filtra.
Estoy leyendo un informe de una compañía de "seguridad de aplicaciones web", que ha estado escaneando algunos sitios web de la empresa para la que estoy trabajando. Parece del informe, que parece escrito sin ninguna participación humana, que se hicieron varios intentos para romper nuestros sitios utilizando solicitudes como esta:
DEBUG /some_path/some_unexisting_file.aspx
Accept: */*
More-Headers: ...
El resultado de nuestro servidor me sorprende:
HTTP/1.1 200 OK
Headers: ...
Como DEBUG no parece mencionarse en ninguna parte de la especificación HTTP 1.1 , esperaba que el resultado fuera 400 Bad Request o 405 Method Not Allowed .
De una pregunta anterior sobre SO , aprendí que el verbo DEBUG se usa en algún tipo de depuración remota de aplicaciones ASP.NET, pero no hay muchos detalles disponibles en esa pregunta o sus respuestas.
Exactamente, ¿para qué se usa el verbo DEBUG ? ¿Por qué la aplicación responde 200 OK para URL inválidas cuando se usa este verbo? ¿Es esto un problema de seguridad? ¿Hay algún problema potencial de seguridad que rodee el verbo DEBUG , que los desarrolladores de ASP.NET / administradores del sistema deben tener en cuenta?
Cualquier información / consejo / referencia será apreciada.
@Mark, @ Jørn, gracias por la excelente información, también me ha llamado la atención sobre esto.
En cuanto a su informe, desde un punto de vista de seguridad, hay otro aspecto (además de RPC y soporte de depuración): superficie de ataque. Es una especie de artículo de bajo riesgo, pero la mejor práctica es generalmente minimizar cualquier interfaz externa que no necesites, de modo que los atacantes potenciales tengan menos espacio para maniobrar y tengan menos probabilidades de encontrar esa falla crítica.
Por cierto, tener activada la compilación de depuración tiene otros efectos, ya que deja más rastros, archivos pdb, etc. alrededor. No necesariamente de alto riesgo, pero aún así ... (sin mencionar el cumplimiento de PCI, si esto es relevante).
Como lo insinuó Mark, el verbo DEBUG se usa para iniciar / detener sesiones remotas de depuración. Más específicamente, una solicitud DEBUG puede contener un encabezado Command con valor start-debug y stop-debug , pero la depuración real se realiza a través de un protocolo RPC.
Entonces, ¿por qué un escáner de seguridad realiza tal solicitud? Parece que introducir un sitio web ASP.NET con las solicitudes DEBUG puede usarse para revelar si web.config tiene <compilation debug="true"> . La prueba se puede realizar con telnet, WFetch o similar, enviando una solicitud como esta:
DEBUG /foo.aspx HTTP/1.0 Accept: */* Host: www.example.com Command: stop-debug
Dependiendo de si la depuración está habilitada o no, obtendrá 200 OK o 403 Forbidden .
En general, se acepta que nunca debe tener <compilation debug="true"/> en un entorno de producción, ya que tiene serias implicaciones en el rendimiento del sitio web. No estoy seguro si la habilitación de la depuración abre nuevos vectores de ataque, a menos que el tráfico RPC también esté habilitado, en cuyo caso usted tiene problemas más serios de todos modos (consulte la respuesta de Mark). Cualquier información adicional sobre la perspectiva de la seguridad será muy apreciada.
Hay una manera fácil de evitar accidentalmente obtener <compilation debug="true"/> en sitios web de producción. Simplemente, agregue <deployment retail="true"/> a su machine.config .
Aparentemente, tener <deployment retail="true"/> en machine.config no es igual a establecer <compilation debug="false"/> en este caso particular. El resultado de arrojar solicitudes DEBUG contra la aplicación web solo se puede cambiar con este último. Alucinante!