我正在阅读“网络应用程序安全”公司的报告，该公司正在扫描我所工作的公司的一些网站。从该报告看来-似乎是在没有任何人为干预的情况下编写的-使用以下请求进行了几次尝试来破坏我们的网站：
DEBUG /some_path/some_unexisting_file.aspx
Accept: */*
More-Headers: ...
我们服务器的结果使我感到惊讶：
HTTP/1.1 200 OK
Headers: ...
[由于DEBUG中似乎没有提到HTTP 1.1 specification，所以我希望结果是400 Bad Request或405 Method Not Allowed。
从earlier question on SO中，我了解到DEBUG动词用于ASP.NET应用程序的某种远程调试中，但是该问题或其答案没有很多可用的详细信息。
DEBUG动词的确切含义是什么？为什么使用该动词时，应用程序为什么会为无效的URL回答200 OK？这是安全问题吗？ ASP.NET开发人员/系统管理员应注意DEBUG动词周围是否存在任何潜在的安全问题？
任何见解/建议/参考都会受到赞赏。
http://support.microsoft.com/kb/937523
当客户端尝试在ASP.NET 2.0应用程序中自动附加调试器时，客户端发送一个包含DEBUG动词的HTTP请求。此HTTP请求用于验证应用程序的进程正在运行，并选择要附加的正确进程。
它使用Windows身份验证，但实际上是DCOM进行调试-因此，我不知道DEBUG动词本身会带来很大的安全风险（显然，如果允许RPC流量，则会遇到更大的问题）或任何利用。不过，默认情况下，UrlScan会阻止它。
我可能在上面放了一个网络嗅探器，以检查哪些信息泄漏了。
如Mark所暗示，DEBUG动词用于启动/停止远程调试会话。更具体地说，DEBUG请求可以包含带有值Command和start-debug的stop-debug标头，但是实际的调试是通过RPC协议完成的。
所以，为什么安全扫描器会执行这样的请求？看来，用DEBUG请求戳ASP.NET网站可以用来揭示web.config是否具有<compilation debug="true">。可以使用telnet，WFetch或类似方法通过发送如下请求来执行测试：
调试/foo.aspx HTTP / 1.0接受：* / *主持人：www.example.com命令：停止调试
取决于是否启用调试，您将获得200 OK或403 Forbidden。
generally accepted绝对不能在生产环境中使用<compilation debug="true"/>，因为它会严重影响网站的性能。我不确定启用调试是否会打开任何新的攻击媒介，除非也启用了RPC通信，在这种情况下，您仍然会遇到更严重的问题（请参阅Mark的回答）。在安全性方面的任何其他见解将不胜感激。
有一种简单的方法可以避免在生产网站中意外获得<compilation debug="true"/>。只需将<deployment retail="true"/>添加到machine.config。
显然，在<deployment retail="true"/>中具有machine.config等于不等于在此特定情况下设置<compilation debug="false"/>。向Web应用程序抛出DEBUG请求的结果只能通过后者更改。令人难以置信！
@@ Mark，@Jørn，感谢您提供的出色信息，对此我也很好奇。至于您的报告，从安全性的角度来看，还有另一个方面（除了RPC和调试支持之外）-攻击面。我说的是低风险项目，但是最佳实践通常是最小化您不需要的任何外部接口，以使潜在的攻击者拥有更少的操作余地，并且发现该关键缺陷的可能性更低。顺便说一句，打开调试编译还有其他效果，因为它确实留下了更多的痕迹，pdb文件等。不一定是高风险，但仍然...（如果相关，更不用说PCI合规性了。）
即使<compilation debug="false"/>，DEBUG动词的确允许潜在的XSS攻击（根据Burp Suite），因为403响应在其主体中包括所请求的URL路径，该URL路径可能包含攻击向量。This fix使IIS返回没有正文的404响应，因此消除了该漏洞。