iis EnableHeaderChecking=true是否足以防止Http Header Injection攻击?

5rgfhyps  于 2023-11-19  发布在  其他
关注(0)|答案(4)|浏览(88)

将[ 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头注入问题,但我还没有找到成功执行攻击的方法。

fv2wmkja

fv2wmkja1#

我已经研究了一段时间,得出的结论是,将EnableHeaderChecking设置为true实际上足以防止http头注入攻击。
查看“反射”的ASP.NET代码,我发现:
1.只有一种方法可以将自定义HTTP标头添加到HTTP响应中,即使用HttpResponse.AppendHeader方法

  • HttpResponse.AppendHeader或者
  • 创建HttpResponseHeader的示例(内部)
  • 或调用HttpResponseHeader.MaybeEncodeHeader(对于IIS7WorkerRequests
  • 或分配其各自的属性(对于已知的头,如RedirectLocationContentType
  • HttpResponseHeader示例是在发送已知头(如RedirectLocationContentType)之前创建的(HttpResponse.GenerateResponseHeaders
  • HttpResponseHeader构造函数检查EnableheaderChecking设置,并在设置为true时调用HttpResponseHeader.MaybeEncodeHeader
  • HttpResponseHeader.MaybeEncodeHeader正确编码换行符,使HTTP头注入攻击无法进行

这里有一个片段来大致演示我是如何测试的:

// simple http response splitting attack
Response.AddHeader("foo", "bar\n" + 
    // injected http response, bad if user provided
    "HTTP/1.1 200 OK\n" + 
    "Content-Length: 19\n" +
    "Content-Type: text/html\n\n" +
    "<html>danger</html>"
);

字符串
只有在显式关闭EnableHeaderChecking的情况下,上述操作才有效:

<httpRuntime enableHeaderChecking="false"/>


Fortify根本不考虑配置(显式设置EnableHeaderChecking没有效果),因此总是报告这些类型的问题。

ih99xse1

ih99xse12#

AFAIK这就足够了,它应该被默认打开。
我认为Fortify只是在考虑深度防御,就像你在部署中改变配置一样。
我假设你没有严格地在你的配置中设置它,如果你有,也许Fortify不是那么聪明,认为我们的。

最好的确认方式是利用它:)

  • 去拿一本《小提琴手》
  • 拦截该请求
  • 尝试注入新线路
  • 查看您刚刚注入的新行是否在HTTP响应中。
wkyowqbh

wkyowqbh3#

EnableHeaderChecking仅适用于不受信任的数据。如果您将数据直接从Cookie传递到重定向,则可能会将生成的标头视为受信任,并且\r\n不会转义值。

sxpgvts3

sxpgvts34#

Josef,HttpResponse.HttpHeader()不是唯一一个不受信任的数据可以进入HTTP响应头的地方。
如果来自攻击者的任何数据包含回车符(或任何被解释为回车符的内容),则这些数据最终会出现在Cookie或HTTP重定向中,并可以写入新的标头。
总的来说,验证数据比坐在那里试图找出漏洞要好得多。很有可能,黑客在这方面比你我更擅长。

相关问题