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

发布于 2024-07-20 02:22:58 字数 591 浏览 10 评论 0原文

拥有 [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 标头注入问题，但我还没有找到成功执行攻击的方法。（编辑：..并且我们打开了 EnableHeaderChecking..）

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

吹泡泡o 2024-07-27 02:22:58

我已经研究这个问题有一段时间了，得出的结论是设置 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 标头注入攻击不可能

这是一个片段，粗略地演示了我的测试方式：

// 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 明确没有效果），因此总是报告此类问题。

I've been looking at this for some time now and draw the conclusion that setting EnableHeaderChecking to true is in fact good enough to prevent http header injection attacks.

Looking at 'reflected' ASP.NET code, I found that:

There is only one way to add custom HTTP headers to an HTTP response, namely using the HttpResponse.AppendHeader method
HttpResponse.AppendHeader either
- creates instances of HttpResponseHeader (internal)
- or calls HttpResponseHeader.MaybeEncodeHeader (for IIS7WorkerRequests)
- or assigns its respective properties (for known headers like RedirectLocation or ContentType)
HttpResponseHeader instances are created before known headers like RedirectLocation or ContentType are sent (HttpResponse.GenerateResponseHeaders)
The HttpResponseHeader constructor checks the EnableheaderChecking setting and calls HttpResponseHeader.MaybeEncodeHeader when set to true
HttpResponseHeader.MaybeEncodeHeader correctly encodes newline characters which makes HTTP header injection attacks impossible

Here is a snippet to roughly demonstrate how I tested:

// 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>"
);

The above only works if you explicitly turn EnableHeaderChecking off:

<httpRuntime enableHeaderChecking="false"/>

Fortify simply doesn't take configuration into account (setting EnableHeaderChecking explicitly had no effect) and thus always reports these type of issues.

回复收藏 0 原文