EnableHeaderChecking=true 是否足以防止 Http Header 注入攻击？答案

【问题标题】：Is EnableHeaderChecking=true enough to prevent Http Header Injection attacks?EnableHeaderChecking=true 是否足以防止 Http Header 注入攻击？
【发布时间】：2009-05-15 15:30:18
【问题描述】：

将 [System.Web.Configuration.HttpRuntimeSection.EnableHeaderChecking](http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85).aspx) 设置为 true（默认）是否足以完全防止响应拆分等 Http Header 注入攻击？

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

【问题讨论】：

标签： asp.net iis security fortify

【解决方案1】：

我已经研究了一段时间，并得出结论，将 EnableHeaderChecking 设置为 true 实际上足以防止 http 标头注入攻击。

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

只有一种方法可以将自定义 HTTP 标头添加到 HTTP 响应中，即使用 HttpResponse.AppendHeader 方法
HttpResponse.AppendHeader 要么
- 创建HttpResponseHeader 的实例（内部）
- 或致电HttpResponseHeader.MaybeEncodeHeader（用于IIS7WorkerRequests）
- 或分配其各自的属性（对于已知的标头，如RedirectLocation 或ContentType）
HttpResponseHeader 实例是在 RedirectLocation 或 ContentType 等已知标头发送之前创建的 (HttpResponse.GenerateResponseHeaders)
HttpResponseHeader 构造函数检查EnableheaderChecking 设置并在设置为true 时调用HttpResponseHeader.MaybeEncodeHeader
HttpResponseHeader.MaybeEncodeHeader 正确编码换行符，这使得 HTTP 标头注入攻击不可能

这是一个 sn-p 来粗略地展示我是如何测试的：

// 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 时，上述方法才有效：

&lt;httpRuntime enableHeaderChecking="false"/&gt;

Fortify 根本不考虑配置（明确设置 EnableHeaderChecking 无效），因此总是报告这类问题。

【讨论】：

嗨，Josef，你上面写的测试注入的代码。我需要到可以粘贴此代码的位置来测试我的应用程序。我还需要测试我的应用程序。谢谢

【解决方案2】：

AFAIK 就够了，应该默认开启。

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

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

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

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

【讨论】：

(: 相信我，我已经尝试过利用它。还有比 fiddler 更好的工具，我个人喜欢 Charles 和 Tamper Data Firefox 插件。

【解决方案3】：

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

【讨论】：

【解决方案4】：

Josef，HttpResponse.AppendHeader() 不是不受信任的数据可以进入 HTTP 响应标头的唯一地方。

如果数据包含回车符（或任何被解释为回车符的内容），则来自攻击者的任何以 Cookie 或 HTTP 重定向结尾的数据都可以写入新标头。

一般来说，利用您的时间来验证您的数据要比坐在那里尝试解决漏洞要好得多。很有可能，黑客在这方面会比你或我做得更好。

【讨论】：

对于众所周知的标头，如 Cookie 或重定向，ASP.NET 已经进行了检查（例如，查看反映的 HttpResponse.Redirect），但 custom 标头都可以使用通过AppendHeader。当然，我们会尽最大努力验证数据，但由于 Fortify 显示了响应拆分攻击和其他攻击，我们查看了 EnableHeaderChecking。