【问题标题】:Reducing information disclosure in Tomcat error pages减少 Tomcat 错误页面中的信息泄露
【发布时间】:2009-10-05 13:44:36
【问题描述】:

默认情况下,Tomcat 的错误页面会披露 Tomcat 的存在以及处理请求的容器的确切版本。这对开发很有好处,但在生产环境中,此信息是一个潜在的安全漏洞,最好禁用它。

因此,我想知道最好的(如最直接/全面的)解决方案是完全抑制 Tomcat 的默认错误页面。我知道 web.xml 中的 <error-page> 选项,但它似乎在两个期望的计数上都失败了,部分原因是我必须多次列出相同的替代错误页面(一个用于我想要处理的每个响应代码),因为这让我觉得可能不是 100% 健壮的;如果攻击者能够以某种方式返回我未明确列出的错误代码,他们将获得默认错误页面。

理想情况下,最好有一个简单的选项来设置通用自定义错误页面,或者完全禁止在默认错误页面中发送任何 HTML 以及错误代码。如果这些选项都不可能,我有兴趣找出实现此功能的典型方法是什么(讨论/显示为什么这些假设选项不存在的奖励积分,因为我的要求似乎是相当标准的对于在生产中使用 Tomcat 的任何人...)。

【问题讨论】:

    标签: tomcat error-handling web-config


    【解决方案1】:

    执行此操作的最简单和最全面的方法是使用 ErrorReportValve - 只需将以下行添加到 server.xml 的 Host 部分(您应该已经拥有 AccessLogValve:

    <Valve className="org.apache.catalina.valves.ErrorReportValve"
        showReport="false" 
        showServerInfo="false"/>    
    

    通过这种方式,您隐藏了服务器信息和(因为可选的 showReport=false)还有堆栈跟踪。

    您可以在Security How ToError Report Valve 的文档中了解更多相关信息。

    【讨论】:

      【解决方案2】:

      &lt;error-page&gt; 是正确的答案,但您不想只是将所有错误代码重定向到一些通用消息。您必须考虑如何处理每个错误。如果您害怕错过其中一个代码,请查看HttpServletResponse interface 中的常量。

      【讨论】:

      • 但我确实想要 - 因为它是一个自包含的 web 应用程序,从用户的角度来看,事情要么正常,要么不正常;他们看到的实际响应确实可以是通用的(日志将向技术人员显示实际问题以及 HTTP 响应代码仍然完好无损)。根据 Tomcat 可能发送的响应代码的枚举,无论如何都接受您的回答。
      • 在默认的tomcat安装中默认安装了一堆webapps,例如'经理','主机经理','例子','tomcat'。看来我需要为每个 webapp 配置全套错误代码,对吧?
      • 哦 - 我刚刚发现了 CATALINA_HOME/conf/web.xml 文件。我已经将 放在那里,但这仍然是个问题,因为我不知道如何让 tomcat 找到引用的文件(或者将我的 error.html 文件放在哪里)。这意味着黑客看到不同的结果取决于他是否查询“/tomcat”和“/foo”,这至少表明我正在使用tomcat。
      【解决方案3】:

      我同意 Jeremy Stein 的观点, 就是答案,但我想补充两点:

      1. 除了应用程序的 web.xml 文件之外,您应该在 CATALINA_HOME/conf/web.xml 文件中添加一个 条目,以防黑客尝试访问其他 Web 应用程序中的 URL比如默认安装的'manager'、'tomcat'、'examples'等。

      2. 如果你想保护服务器,它(显然)不像处理这些错误页面那么简单。此链接列出了您需要做的事情:

      https://www.owasp.org/index.php/Securing_tomcat

      【讨论】:

        【解决方案4】:

        有些错误是由容器直接发送的,您的应用程序没有机会处理它们。例如,当请求一个不存在的资源时,将发送 404 错误。您的应用程序可以对其进行处理的唯一方法是在 web.xml 中声明适当的 &lt;error-page&gt; 条目。

        我同意 Jeremy Stein 的观点,即 &lt;error-page&gt; 是正确答案。毕竟错误代码不是无限的。

        另请阅读here 的讨论,了解如何使用 Spring MVC 处理错误。我认为最重要的是处理自己的错误(如果没有被捕获的异常将导致 500 Internal Server Error)。

        【讨论】:

          【解决方案5】:

          一个可能的选择是设置一个 Servlet 过滤器,它可以将错误页面重定向到您想要的页面......您只需编写一次,它适用于所有错误代码..

          【讨论】:

          • 一种有趣的方法...我怀疑它可能有点脆弱并且会破坏性能,因为我需要解析每个响应以尝试从原始数据中解决字符,无论它是否是默认错误页面。或者有没有更好的方法来识别问题页面?
          • @dtsazza 在性能方面,如果将隐含的几十条指令与整个请求处理过程中涉及的上万条指令进行比较,不到 0.1%。 当代码级别如此之高时,性能影响可以忽略不计
          猜你喜欢
          • 2016-06-21
          • 2021-04-08
          • 2014-10-25
          • 1970-01-01
          • 2012-10-08
          • 2011-05-25
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多