.net – 默认启用UnsafeHeaderParsing是否可以接受？

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

我在项目开发中很早就遇到的一个问题是,我用作测试用例的一些提要(即Hacker News RSS feed)使用了格式不正确的HTTP标头,以及.NET 1.1及更高版本中的HttpWebRequest类每当您在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”配置选项,但它在该应用程序的上下文中的所有HttpWebRequests中执行.我有用户抱怨QD Feed Parser无法使用有效的Feed,这个标头问题就是原因.

现在,我的库设置方式使得使用它的开发人员必须自己启用不安全的头解析,尽管他们中的大多数都不知道这是问题而且它为我创建了支持开销.

我可以简单地让Quick and Dirty Feed Parser默认启用不安全的头解析,并强制安全性的用户禁用它,但我不想打开对安全攻击不了解的用户.这里最好的选择是什么？

解决方法

“不安全”在这里有点极端;我会以不同的方式命名此设置.当不良行为的服务器发出不完全遵循HTTP RFC的标头时,问题就出现了.例如,RFC说CR字符后面必须跟一个LF字符,所以如果没有LF,除非你允许“不安全”的标题,否则你会得到一个execption.

实际上,许多HTTP客户端忽略这些轻微违规,以便与尽可能多的服务器通信.这就是为什么你的浏览器或RSS阅读器永远不会抱怨“不安全”的标题.即使标头是虚假的,.NET客户端库也足够强大,例如,如果恶意攻击者省略了换行符,您就不会崩溃服务器. :-)所以这里没有一个很大的安全问题,除非(例如)你用HTTP标题名称做愚蠢的事情,比如将它们直接发送到你的HTML中(这可能允许攻击者在你的HTML中注入XSS攻击).

因此,只要您将HTTP标头视为与您的应用程序中的任何其他用户提交的数据(如查询字符串,POST数据等)一样不值得信任,那么您应该可以允许“不安全”您应用中的标题.