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

【问题标题】：What is the non-standard HTTP verb "DEBUG" used for in ASP.NET/IIS?ASP.NET/IIS 中使用的非标准 HTTP 动词“DEBUG”是什么？
【发布时间】：2011-01-15 16:51:42
【问题描述】：

我正在阅读一家“网络应用程序安全”公司的报告，该公司一直在扫描我工作的公司的一些网站。从报告中可以看出——该报告似乎没有任何人为参与——曾多次尝试使用以下请求破坏我们的网站：

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 动词的具体用途是什么？为什么应用程序在使用此动词时会回答 200 OK 的无效 URL？这是一个安全问题吗？围绕DEBUG 动词是否存在任何潜在的安全问题，ASP.NET 开发人员/系统管理员应该注意这些问题？

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

【问题讨论】：

你解决了吗？我看到你已经接受了一个答案，但它只告诉你使用网络嗅探器。即使这是 6 年后的事。

标签： asp.net security http iis debugging

【解决方案1】：

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

【讨论】：

好的。但是您知道如何利用它吗？现代网络浏览器中的 DEBUG 动词是否未被阻止？
@cactuschibre Postman、telnet、其他应用程序和浏览器扩展允许它。
我的意思是获取真正 XSS 的漏洞，而不是工具 :)

【解决方案2】：

正如 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。~~

显然，在这种特殊情况下，machine.config 中的<deployment retail="true"/> 不等于设置 <compilation debug="false"/>。向 Web 应用程序抛出 DEBUG 请求的结果只能用后者更改。令人难以置信！

【讨论】：

仅供参考，“命令：停止调试”标头在测试时很重要。如果你把它排除在外，服务器只会返回 500。

【解决方案3】：

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

【讨论】：

【解决方案4】：

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

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

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

我可能会在上面安装一个网络嗅探器来检查哪些信息泄露了。

【讨论】：