¿Para qué se utiliza el verbo HTTP no estándar "DEBUG" en ASP.NET/IIS?

Question

Estoy leyendo un informe de una empresa de "seguridad de aplicaciones web", que ha estado escaneando algunos sitios web de la empresa para la que estoy trabajando. Se desprende del informe - que parece estar escrito sin ninguna intervención humana - que varios intentos donde hecho para romper nuestros sitios utilizando demandas como éste:

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 ningún lugar en el HTTP 1.1 specification, esperaba que el resultado fuera 400 Bad Request o 405 Method Not Allowed.

De earlier question on SO, he aprendido que el verbo DEBUG se utiliza 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 utiliza 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 de seguridad potencial 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.

Answer 1

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 de depuración. 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.

Se utiliza la autenticación de Windows, y DCOM para hacer realidad la depuración sin embargo - así que no estoy al tanto de la propia verbo DEBUG siendo un gran riesgo para la seguridad (obviamente, si se va a permitir el tráfico RPC, entonces' Tengo problemas más grandes) o de cualquier exploits. UrlScan sí lo bloquea por defecto, sin embargo.

Probablemente pondría un detector de red para verificar qué información se filtra.

Answer 2

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 el 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 se puede utilizar un sitio web ASP.NET con las solicitudes DEBUG para revelar si el web.config tiene <compilation debug="true">. La prueba puede realizarse con telnet, WFetch o similares, mediante el envío de una petición como esta:

 
DEBUG /foo.aspx HTTP/1.0 
Accept: */* 
Host: www.example.com 
Command: stop-debug 

Dependiendo de si la depuración está habilitado o no, obtendrá ya sea 200 OK o 403 Forbidden.

Es generallyaccepted que nunca se 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 los sitios web de producción. Simplemente, agregue <deployment retail="true"/> a su machine.config.

Al parecer, teniendo <deployment retail="true"/> en el machine.config es no igual a la configuración <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!

Answer 3

@Mark, @ Jørn, gracias por la excelente información, también me ha llamado la atención.
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)