EnableHeaderChecking=true是否足以防止Http头注入攻击？
将System.Web.Configuration.HttpRuntimeSection.EnableHeaderChecking](http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85%29.aspx%29)设置为true (默认)以完全防止Http头注入攻击(如响应拆分等)是否足够？
我之所以问这个问题，是因为一个白盒渗透测试工具(fortify)报告了HttpResponse.Redirect和cookies中可利用的http头注入问题，但我还没有找到成功执行攻击的方法。(编辑：..and我们打开了EnableHeaderChecking .)
回答 4
Stack Overflow用户
发布于 2009-05-22 15:30:41
我已经研究了一段时间，并得出这样的结论:将EnableHeaderChecking设置为true实际上足以防止http头注入攻击。
查看“反射”ASP.NET代码，我发现：
- 只有一种方法可以将自定义headers添加到HTTP响应中，即使用HttpResponse.AppendHeader方法
- HttpResponse.AppendHeader或
- 创建
HttpResponseHeader实例(内部) - 或调用
HttpResponseHeader.MaybeEncodeHeader(用于IIS7WorkerRequests) - 或指定其各自的属性(对于已知的标头，如RedirectLocation或ContentType)
- 创建
HttpResponseHeader实例是在发送RedirectLocation或ContentType等已知标头之前创建的(HttpResponse.GenerateResponseHeaders)HttpResponseHeader构造函数检查EnableheaderChecking设置并在设置为true时调用HttpResponseHeader.MaybeEncodeHeaderHttpResponseHeader.MaybeEncodeHeader正确编码换行符，使header注入攻击成为不可能
下面是一个片段，可以粗略演示我是如何测试的：
// 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，因此总是报告这类问题)。
Stack Overflow用户
发布于 2009-05-19 09:45:46
AFAIK --它已经足够了，它应该默认打开。
我认为Fortify只是在深入考虑防御，就好像您改变了部署中的配置一样。
我假设您在配置中没有严格地设置它，如果您有，那么Fortify并不是那么聪明。
确认的最佳方法是利用它:)
- 只要拿到一份小提琴的副本
- 拦截请求
- 尝试注入新行
- 看看您刚才注入的新行是否在HTTP响应中。
Stack Overflow用户
发布于 2009-05-19 09:38:00
EnableHeaderChecking只适用于不受信任的数据。如果您直接将数据从cookie传递到重定向，则可能结果头被认为是可信的，\r\n值不会转义。
https://stackoverflow.com/questions/869361
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号