代码之家  ›  专栏  ›  技术社区  ›  Josef Pfleger

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

  •  10
  • Josef Pfleger  · 技术社区  · 16 年前

    System.Web.Configuration.HttpRuntimeSection.EnableHeaderChecking ]( http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85).aspx) true (默认)完全防止Http头注入攻击,如响应拆分等。?

    HttpResponse.Redirect Cookie,但我还没有找到成功执行攻击的方法。 ( 编辑 :..并且我们启用了EnableHeaderCheck。.)

    4 回复  |  直到 15 年前
        1
  •  7
  •   Josef Pfleger    16 年前

    我对此已经研究了一段时间,得出的结论是 EnableHeaderChecking true 事实上,它足以防止http标头注入攻击。

    查看“反映”的ASP。NET代码,我发现:

    1. 只有一种方法可以将自定义HTTP标头添加到HTTP响应中,即使用 HttpResponse.AppendHeader 方法
    2. Http响应。附录标题 要么
      • 创建以下实例 HttpResponseHeader (内部)
      • 或致电 HttpResponseHeader.MaybeEncodeHeader (为 IIS7WorkerRequests )
      • 或分配其各自的属性(对于已知的标头,如 RedirectLocation ContentType )
    3. HttpResponseHeader 实例是在已知标头之前创建的,例如 重定向位置 内容类型 已发送( HttpResponse.GenerateResponseHeaders )
    4. HttpResponseHeader 构造函数检查 EnableheaderChecking 设置和呼叫 HttpResponseHeader。MaybeEncodeHeader 当设置为
    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>"
    );
    

    只有当你明确地转向 EnableHeaderCheck

    <httpRuntime enableHeaderChecking="false"/>

    Fortify根本不考虑配置(设置 EnableHeaderCheck 明确没有效果),因此 总是 报告这些类型的问题。

        2
  •  1
  •   dr. evil    16 年前

    AFAIK已经足够了,应该默认打开。

    我认为Fortify只是在考虑深度防御,就像你在部署中改变配置一样。

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

    • 买一份小提琴手
    • 拦截请求
    • 尝试注入新线
    • 查看您刚刚注入的新行是否在HTTP响应中。
        3
  •  0
  •   nessence    16 年前

    EnableHeaderCheck仅适用于不受信任的数据。如果您将数据直接从cookie传递到Redirect,则生成的标头可能被视为可信的,\r\n值不会转义。

        4
  •  0
  •   Douglas Held    15 年前

    约瑟夫,HttpResponse。AppendHeader()并不是不受信任的数据可以输入HTTP响应头的唯一地方。

    如果来自攻击者的任何数据包含回车符(或任何被解释为回车符的内容),则最终出现在Cookie或HTTP重定向中的数据都可以写入新的标头。

    一般来说,验证数据比坐在那里试图找出漏洞要好得多。很有可能,黑客在这方面会比你我做得更好。