ASP.NET / IIS远程调试 - DEBUG动词

Question

I'm looking for details on the DEBUG HTTP verb.
It's clear to me that this is used for remote debugging - though I'm not even sure if it's for IIS or ASP.NET...

If I want to access this interface directly - ie not through Visual Studio, but sending these commands manually - what do I need to know? What are the commands for it?
I'm also interested in misuse cases, if you have any information on that...

Answer 1

Just for completeness, consolidating here the answers from what-is-the-non-standard-http-verb-debug-used-for-in-asp-net-iis : (thanks @Mark, @Jørn).

http://support.microsoft.com/kb/937523

When the client tries to automatically attach the debugger in an ASP.NET 2.0 application, the client sends a HTTP request that contains the DEBUG verb. This HTTP request is used to verify that the process of the application is running and to select the correct process to attach.

The DEBUG verb is used to start/stop remote debugging sessions. More specifically, a DEBUG request can contain a Command header with value start-debug and stop-debug , but the actual debugging is done via an RPC protocol.

It uses Windows authentication, and DCOM to actually do the debugging though (obviously, if you're allowing RPC traffic, then you've got bigger problems) or of any exploits. UrlScan does block it by default, though.

However, poking an ASP.NET website with the DEBUG requests can be used to reveal if the web.config has <compilation debug="true"> . The test can be performed with telnet, WFetch or similar, by sending a request like this:

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

Depending on whether debugging is enabled or not, you will get either 200 OK or 403 Forbidden .

It is generally accepted that you should never have <compilation debug="true"/> in a production environment, as it has serious implications on the performance of the website. I am not sure if having debugging enabled opens any new attack vectors, unless RPC traffic is enabled as well, in which case you have more serious problems anyway.

Answer 2

If you want to do remote debugging, I would suggest utilizing debug.writeline and the tool from sysinternals DebugView . This allows you to 'listen' for debug statements either on your location machine or on a remote machine, provided you have the necessary access.

I cannot directly answer the part about DEBUG http as I am unfamiliar with it.