ASP.NET / IIS中使用的非标准HTTP动词“DEBUG”是什么？

Question

我正在阅读一家“网络应用程序安全”公司的报告，该公司一直在扫描我正在为之工作的公司的几个网站。从报告中看来 - 似乎是在没有任何人为参与的情况下编写的 - 有几次尝试使用这样的请求打破我们的网站：

DEBUG /some_path/some_unexisting_file.aspx
Accept: */*
More-Headers: ...

我们服务器的结果令我感到惊讶：

HTTP/1.1 200 OK
Headers: ...

HTTP 1.1 specification似乎没有在earlier question on SO的任何地方提到DEBUG，我预计结果会是400 Bad Request或405 Method Not Allowed。

从{{3}}开始，我了解到DEBUG动词用于ASP.NET应用程序的某种远程调试，但在该问题或其答案中没有很多细节。

究竟用于DEBUG动词是什么？使用此动词时，为什么应用程序会回答200 OK无效的网址？这是安全问题吗？围绕{/ 1}}动词存在任何潜在的安全问题，ASP.NET开发人员/系统管理员应该注意这些问题吗？

任何见解/建议/参考将不胜感激。

Answer 1

正如Mark所暗示的，DEBUG动词用于启动/停止远程调试会话。更具体地说，DEBUG请求可以包含值为Command和start-debug的{​​{1}}标头，但实际调试是通过RPC协议完成的。

那么，为什么安全扫描程序会执行此类请求？看来，使用stop-debug请求戳一个ASP.NET网站可以显示DEBUG是否有web.config。可以使用telnet，WFetch或类似方法执行测试，方法是发送如下请求：

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

根据是否启用调试，您将获得<compilation debug="true">或200 OK。

generally accepted在生产环境中永远不应该403 Forbidden，因为它会对网站的性能产生严重影响。我不确定启用调试是否会打开任何新的攻击媒介，除非启用了RPC流量，在这种情况下你还有更严重的问题（参见Mark的回答）。任何有关安全性观点的其他见解将不胜感激。

有一种简单的方法可以避免在生产网站中意外获取<compilation debug="true"/>。只需将<compilation debug="true"/>添加到<deployment retail="true"/>。

显然，machine.config中的<deployment retail="true"/> 等于在此特定情况下设置machine.config。针对Web应用程序发出<compilation debug="false"/>请求的结果只能通过后者进行更改。令人难以置信！

Answer 2

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

  

当客户端尝试在ASP.NET 2.0应用程序中自动附加调试器时，客户端会发送包含DEBUG谓词的HTTP请求。此HTTP请求用于验证应用程序的进程是否正在运行，并选择要附加的正确进程。

它使用Windows身份验证和DCOM实际进行调试 - 所以我不知道DEBUG动词本身存在很大的安全风险（显然，如果你允许RPC流量，那么你就会变大问题）或任何漏洞。但是，UrlScan默认会阻止它。

我可能会在其上放置一个网络嗅探器，以检查泄漏的信息。

Answer 3

@Mark，@Jørn，感谢您提供的优秀信息，我也对此感到好奇 至于你的报告，从安全的角度来看，还有另外一个方面（除了RPC和调试支持） - 攻击面。我是一种低风险项目，但最佳做法通常是尽量减少您不需要的任何外部接口，以便潜在的攻击者有更少的操作空间，并且发现一个关键缺陷的可能性较低。
顺便说一句，打开调试编译有其他影响，因为它会留下更多的痕迹，pdb文件等。不一定是高风险，但仍然......（更不用说PCI合规性，如果这是相关的。）

Answer 4

即使使用<compilation debug="false"/>，DEBUG动词的确允许潜在的XSS攻击（根据Burp Suite），因为403响应的主体中包含所请求的URL路径，该路径可能包含攻击向量。 This fix使IIS返回没有正文的404响应，因此消除了该漏洞。