10

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

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

4

4 回答 4

7

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

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

  1. 只有一种方法可以将自定义 HTTP 标头添加到 HTTP 响应，即使用HttpResponse.AppendHeader方法
  2. HttpResponse.AppendHeader要么
    • 创建HttpResponseHeader（内部）的实例
    • 或调用HttpResponseHeader.MaybeEncodeHeader(for IIS7WorkerRequests)
    • 或分配其各自的属性（对于已知的标头，如RedirectLocation或ContentType）
  3. HttpResponseHeader在发送RedirectLocation或ContentType等已知标头之前创建实例（HttpResponse.GenerateResponseHeaders）
  4. 构造HttpResponseHeader函数检查EnableheaderChecking设置并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>"
);

以上仅在您明确关闭EnableHeaderChecking时才有效：

<httpRuntime enableHeaderChecking="false"/>

Fortify 根本不考虑配置（显式设置EnableHeaderChecking无效），因此总是报告这些类型的问题。

于 2009-05-22T15:30:41.610 回答
1

AFAIK 就足够了，它应该默认打开。

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

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

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

  • 只需获取 fiddler 的副本
  • 拦截请求
  • 尝试注入新行
  • 查看您刚刚注入的新行是否在 HTTP 响应中。
于 2009-05-19T09:45:46.103 回答
0

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

于 2009-05-19T09:38:00.800 回答
0

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

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

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

于 2010-07-22T23:06:55.027 回答