【问题标题】:Tomcat security-constraints TRACE inconsistentTomcat 安全约束 TRACE 不一致
【发布时间】:2014-09-23 14:11:45
【问题描述】:

我正在使用 web.xml 来尝试禁用我们不使用的 HTTP 方法并返回一个不包含任何 tomcat 信息的正文。

所以我已将应用的 web.xml 更改为:

<security-constraint>
    <web-resource-collection>
        <web-resource-name>restricted methods</web-resource-name>
        <url-pattern>/*</url-pattern>
        <http-method>TRACE</http-method>
        <http-method>PUT</http-method>
        <http-method>OPTIONS</http-method>
        <http-method>DELETE</http-method>
        <http-method>HEAD</http-method>
    </web-resource-collection>
    <auth-constraint />
</security-constraint>

因此,被阻止的方法返回 403 并带有一个空主体,表示禁止。但是 TRACE 会返回一个带有 Tomcat HTML 页面的 405。

我尝试通过 ErrorServlet 重定向所有错误:

<error-page>
    <location>/ErrorServlet</location>
</error-page>

这只是确保内容主体为 0。但这似乎并没有拦截这些。

那么,为什么 TRACE 会受到不同的对待?

谢谢

【问题讨论】:

    标签: java tomcat tomcat7 web.xml


    【解决方案1】:

    这对我来说很有意义,因为在除 TRACE 之外的所有情况下,您都在提交对由 URL 标识的 Web 资源的请求,并且代码 403 意味着对该资源的访问被拒绝。尝试使用允许的方法访问相同的资源。可能他们也被禁止了?

    另一方面,TRACE 不需要访问任何资源,它只是回显客户端的输入,因此 405(“方法不允许”)看起来适合这种情况。

    拥有自定义错误页面是个好主意。可以在此处找到每个错误代码的特定示例:https://serverfault.com/questions/254102/custom-error-pages-on-apache-tomcat

    【讨论】:

    • 谢谢。好吧,我们试图总是返回空主体,因为它是一个没有视图元素的休息 api。所以将 html 发送回 C++ 客户端有点浪费。为了安全起见,我们想尝试并禁止所有 tomcats 正常错误页面。
    • 为 405 页面添加 /ErrorServlet 的特定错误页面似乎已经成功了。
    • 安全方面,这是一个非常适合 API 的好主意,但是如果您正在与实时用户和浏览器打交道,最好在不提供任何技术细节的情况下生成通用消息 - 它'将使黑客的生活更加困难:)
    猜你喜欢
    • 1970-01-01
    • 2018-05-05
    • 2010-11-08
    • 2020-11-04
    • 2014-11-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-09-10
    相关资源
    最近更新 更多