EnableHeaderChecking=true 是否足以防止 Http 标头注入攻击？

StackOverflow https://stackoverflow.com/questions/869361

  •  22-08-2019
  •  | 
  •  

题

拥有[就足够了吗？System.Web.Configuration.HttpRuntimeSection.EnableHeaderChecking](http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85).aspx) 设置 true （默认）完全防止 Http 标头注入攻击，例如响应拆分等？

我问这个问题是因为白盒渗透测试工具（fortify）报告了可利用的http标头注入问题 HttpResponse.Redirect 和 cookies，但我还没有找到成功执行攻击的方法。（编辑:..并且我们打开了 EnableHeaderChecking..）

有帮助吗？

解决方案

我已经研究这个有一段时间了，得出的结论是设置 启用标头检查 到 true 事实上足以防止 http 标头注入攻击。

查看“反射”的 ASP.NET 代码，我发现：

  1. 只有一种方法可以将自定义 HTTP 标头添加到 HTTP 响应，即使用 HttpResponse.AppendHeader 方法
  2. HttpResponse.AppendHeader 任何一个
    • 创建实例 HttpResponseHeader （内部的）
    • 或致电 HttpResponseHeader.MaybeEncodeHeader （为了 IIS7WorkerRequests)
    • 或分配其各自的属性（对于已知的标头，例如 重定向位置 或者 内容类型)
  3. HttpResponseHeader 实例是在已知标头之前创建的，例如 重定向位置 或者 内容类型 已发送（HttpResponse.GenerateResponseHeaders)
  4. 这 HttpResponseHeader 构造函数检查 启用标头检查 设置和通话 HttpResponseHeader.MaybeEncodeHeader 当设置为 true
  5. 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>"
);

仅当您明确转向时，上述内容才有效 启用标头检查 离开：

<httpRuntime enableHeaderChecking="false"/>

Fortify 根本不考虑配置（设置 启用标头检查 明确没有效果），因此 总是 报告此类问题。

其他提示

AFAIK 这已经足够了，它应该默认打开。

我认为 Fortify 只是考虑深度防御，就像更改部署中的配置等一样。

我假设你没有在你的配置中严格设置它，如果你有，也许 Fortify 没有那么聪明地认为我们的。

确认的最佳方法是利用它:)

  • 只需获取一份 fiddler 副本即可
  • 拦截请求
  • 尝试注入新行
  • 查看您刚刚注入的新行是否在 HTTP 响应中。

EnableHeaderChecking仅用于不可信数据。如果您是直接从cookie中的数据传递到重定向，也许导致头被认为是值得信赖和\ r \ n值都没有逃过。

约瑟夫，HttpResponse.AppendHeader（）不是其中不可信数据可进入HTTP响应头的唯一地方。

这在饼干或HTTP重定向最终如果该数据包含一个回车（或任何被解释为回车）可以写入新的报头中的攻击者的任何数据。

在一般情况下，这是一个更好的利用你的时间，以验证您的数据，而不是坐在那里，并尝试找出漏洞。机会是，黑客将是更好的在这方面比你或我是。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top