默认情况下启用 UnsafeHeaderParsing 是不是可以接受？

Posted 2023-05-07

【中文标题】默认情况下启用 UnsafeHeaderParsing 是不是可以接受？

【英文标题】：Is it an acceptable practice to enable UnsafeHeaderParsing by default?默认情况下启用 UnsafeHeaderParsing 是否可以接受？

【发布时间】：2011-05-31 20:42:59

【问题描述】：

这是一个有点主观的问题，但我想听听这样做的利弊。我管理一个名为 Quick and Dirty Feed Parser 的开源项目，该项目的目标是尽可能无缝地在 .NET 中使用 RSS 和 Atom 提要。

我在项目开发早期遇到的一个问题是，我用作测试用例的一些提要（即Hacker News RSS feed）使用了格式不正确的 HTTP 标头，以及 . NET 1.1 及更高版本在 GET 请求中收到这些标头之一时会立即引发“不安全标头”异常。

This change was added in order to put a stop to split-response attacks that were raising security issues at the time .NET 1.1 was released.

因此，我的问题是 - 我可以以编程方式启用“useUnsafeHeader”配置选项，但它会在该应用程序的上下文中跨所有 HttpWebRequest 执行此操作。我有用户抱怨 QD Feed Parser 无法使用有效的提要，这个标题问题就是原因。

现在我的库以这样一种方式设置，即使用它的开发人员必须自己启用不安全的标头解析，尽管他们中的大多数人不知道这是问题所在，并且它给我带来了支持开销。

我可以简单地让 Quick and Dirty Feed Parser 在默认情况下启用不安全的标头解析并强制具有安全意识的用户禁用它，但我也不想让对安全攻击一无所知的用户开放。这里最好的选择是什么？

【问题讨论】：

我刚刚访问了项目站点并注意到第一页中没有“FAQ”页面，尽管您已经在其他地方的“高级用法”中记录了这个问题（不是很明显）。使您的文档可预测且易于查找还可以为您节省支持开销。

【参考方案1】：

“不安全”在这里有点极端；我会以不同的方式命名此设置。当行为不端的服务器发出不完全遵循 HTTP RFC 的标头时，就会出现问题。例如，RFC 规定 CR 字符必须后跟一个 LF 字符，因此如果没有 LF，除非您允许“不安全”标头，否则您将得到一个执行。

实际上，许多 HTTP 客户端会忽略这些轻微的违规行为，以便与尽可能多的服务器通信。这就是您的浏览器或 RSS 阅读器从不抱怨“不安全”标题的原因。即使标头是伪造的，.NET 客户端库也足够健壮，例如，如果恶意攻击者忽略换行，您不会导致服务器崩溃。 :-) 所以这里实际上并没有什么大的安全问题，除非（例如）你用 HTTP 标头名称做一些愚蠢的事情，比如将它们直接发送到你的 html 中（这可能允许攻击者将 XSS 攻击注入到你的 HTML 中）。

因此，只要您将 HTTP 标头视为与进入您的应用程序的任何其他用户提交的数据（如查询字符串、POST 数据等）一样不可信，那么您应该可以允许应用程序中的“不安全”标头。