将[ System.Web.Configuration.HttpRuntimeSection.EnableHeaderChecking
](http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85).aspx)))设置为true
(默认值)是否足以完全防止HTTP头注入攻击,如响应分裂等?
我问这个问题是因为一个白色盒子渗透测试工具(fortify)报告了HttpResponse.Redirect
和cookie的可利用的HTTP头注入问题,但我还没有找到成功执行攻击的方法。
4条答案
按热度按时间fv2wmkja1#
我已经研究了一段时间,得出的结论是,将EnableHeaderChecking设置为
true
实际上足以防止http头注入攻击。查看“反射”的ASP.NET代码,我发现:
1.只有一种方法可以将自定义HTTP标头添加到HTTP响应中,即使用HttpResponse.AppendHeader方法
HttpResponseHeader
的示例(内部)HttpResponseHeader.MaybeEncodeHeader
(对于IIS7WorkerRequests
)HttpResponseHeader
示例是在发送已知头(如RedirectLocation或ContentType)之前创建的(HttpResponse.GenerateResponseHeaders
)HttpResponseHeader
构造函数检查EnableheaderChecking设置,并在设置为true
时调用HttpResponseHeader.MaybeEncodeHeader
HttpResponseHeader.MaybeEncodeHeader
正确编码换行符,使HTTP头注入攻击无法进行这里有一个片段来大致演示我是如何测试的:
字符串
只有在显式关闭EnableHeaderChecking的情况下,上述操作才有效:
型
Fortify根本不考虑配置(显式设置EnableHeaderChecking没有效果),因此总是报告这些类型的问题。
ih99xse12#
AFAIK这就足够了,它应该被默认打开。
我认为Fortify只是在考虑深度防御,就像你在部署中改变配置一样。
我假设你没有严格地在你的配置中设置它,如果你有,也许Fortify不是那么聪明,认为我们的。
最好的确认方式是利用它:)
wkyowqbh3#
EnableHeaderChecking仅适用于不受信任的数据。如果您将数据直接从Cookie传递到重定向,则可能会将生成的标头视为受信任,并且\r\n不会转义值。
sxpgvts34#
Josef,HttpResponse.HttpHeader()不是唯一一个不受信任的数据可以进入HTTP响应头的地方。
如果来自攻击者的任何数据包含回车符(或任何被解释为回车符的内容),则这些数据最终会出现在Cookie或HTTP重定向中,并可以写入新的标头。
总的来说,验证数据比坐在那里试图找出漏洞要好得多。很有可能,黑客在这方面比你我更擅长。