Question

将[System.Web.Configuration.HttpRuntimeSection.EnableHeaderChecking]（http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85).aspx)设置为true（默认值）是否足以完全阻止Http Header Injection攻击，例如Response Splitting等。

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

Answer 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设置，并在设置为HttpResponseHeader.MaybeEncodeHeader时调用true
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没有效果），因此总是报告这些类型的问题。

Answer 2

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

我认为Fortify只是考虑深度防御，就好像你改变了部署中的配置等。

我认为你没有在你的配置中严格设置它，如果你有可能Fortify不是那么聪明的想法我们。

最佳确认方法是利用它：）

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

Answer 3

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

Answer 4

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

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

通常，您可以更好地利用时间来验证数据，而不是坐下来尝试解决漏洞。很可能，黑客在这方面会比你或我更好。

EnableHeaderChecking = true是否足以阻止Http Header Injection攻击？

4 个答案: