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 规范中似乎没有任何地方提到DEBUG ，我原以为结果是400 Bad Request或405 Method Not Allowed 。

从之前关于 SO 的问题中，我了解到DEBUG动词用于 ASP.NET 应用程序的某种远程调试，但该问题或其答案中提供的详细信息并不多。

DEBUG动词究竟是做什么用的？ 为什么应用程序在使用此动词时对无效 URL 回答200 OK ？ 这是一个安全问题吗？ ASP.NET 开发人员/系统管理员应该注意围绕DEBUG动词是否存在任何潜在的安全问题？

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

Answer 1

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

那么，为什么安全扫描器会执行这样的请求呢？ 似乎可以使用DEBUG请求戳 ASP.NET 网站来揭示web.config是否具有<compilation debug="true"> 。 可以使用 telnet、 WFetch或类似工具执行测试，方法是发送如下请求：

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

根据是否启用调试，您将获得200 OK或403 Forbidden 。

人们普遍接受的是你不应该<compilation debug="true"/>在生产环境，因为这对网站的性能造成严重影响。 我不确定启用调试是否会打开任何新的攻击媒介，除非也启用了 RPC 流量，在这种情况下，无论如何您都会遇到更严重的问题（参见 Mark 的回答）。 任何有关安全角度的其他见解将不胜感激。

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

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

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和调试支持）——攻击面。 I 是一种低风险项目，但最佳实践通常是尽量减少您不需要的任何外部接口，以便潜在攻击者的操作空间较小，并且发现该关键缺陷的可能性较低。
顺便说一句，打开调试编译还有其他影响，因为它确实会留下更多的痕迹、pdb 文件等。 不一定是高风险，但仍然......（更不用说 PCI 合规性，如果这是相关的。）

Answer 4

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