Aar*_*web 7 .net asp.net security asp.net-mvc wcf
这是一个有点主观的问题,但我想听听这样做的优点/缺点.我管理一个名为Quick and Dirty Feed Parser的开源项目,该项目的目标是尽可能无缝地使用.NET中的RSS和Atom提要.
我在项目开发中很早就遇到的一个问题是我使用的一些提要作为测试用例(即黑客新闻RSS提要)使用了格式不正确的HTTP标头,以及.NET 1.1中的HttpWebRequest类并且只要您在GET请求中收到其中一个标头,就会立即抛出"不安全的标头"异常.
添加此更改是为了阻止在.NET 1.1发布时引发安全问题的分裂响应攻击.
因此我的问题是 - 我可以以编程方式启用"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数据等)一样不值得信任,那么您应该可以选择"不安全"您应用中的标题.