web.xml文件中的7个错误的安全配置

关于Java的web.xml文件中配置认证和授权有大 量 的 文章。本文不再去重新讲解如何配置角色、保护web资源和设置不同类型的认证，让我们来看看web.xml文件中的一些常见的安全错误配置。

(1) 自定义的错误页面没有配置

默认情况下，Java Web应用在发生错误时会将详细的错误信息展示出来，这将暴露服务器版本和详细的堆栈信息，在有些情况下，甚至会显示Java代码的代码片段。这些信息对为他们的病毒需找更多信息的黑客来说是一种恩惠。幸运的是，通过配置web.xml文件来展示自定义的错误页面是非常容易的。使用如下的配置后无论服务器在任何时候发生HTTP500错误，一个非常好的错误页面就会被显示出来。你可以为HTTP状态码添加另外的错误页面。

?

1 2 3 4

<error-page>         <error-softwaresecurity>500</error-softwaresecurity>         <location>/path/to/error.jsp</location> </error-page>

另外，web.xml文件应该被配置以防止详细的错误堆栈信息被显示出来，我们可以通过配置<exception-type>来实现。因为Throwable是Java中所有Exception和Error的基类，下面的代码片段将很好的确保堆栈信息不被服务器显示。

?

1 2 3 4

<error-page>         <exception-type>java.lang.Throwable</exception-type>         <location>/path/to/error.jsp</location> </error-page>

然而，如果你采用如下的处理方式，你依然会将堆栈信息展示出来：

<%
try {
        String s = null;
        s.length();
} catch (Exception e) {
        // don't do this!
        e.printStackTrace(new PrintWriter(out));
}
%>

这里请记住在合理配置了你的web.xml文件后，需要使用合理的日志记录技巧。

(2)绕过认证和授权

下面的代码片段展示了如何设置基于web的访问控制以便所有在”安全”目录中的一切只能被带有”admin”角色的用户访问。

?

1 2 3 4 5 6 7 8 9 10 11

<security-constraint>         <web-resource-collection>                 <web-resource-name>secure</web-resource-name>                 <url-pattern>/secure/*</url-pattern>                 <http-method>GET</http-method>                 <http-method>POST</http-method>         </web-resource-collection>         <auth-constraint>                 <role-name>admin</role-name>         </auth-constraint> </security-constraint>

从常识观点来看，指定了GET和POST的<http-method>元素限定了*只有*GET和POST请求是被允许的。事实上不是这样，任意未列举的HTTP方法实际上都是允许使用的，即采用其他的HTTP方法可以绕过认证和授权。Arshan Dabirsiaghi有一个非常好的论文总结了该问题并向你展示了如何使用上述配置中未列举的任意的HTTP动词（像HEAD）和完全假冒的动词（像TEST或JUNK）来绕过web.xml中配置的认证和授权保护。

幸运的是，解决方案非常简单。仅仅需要从web.xml文件中移除<http-method>元素即可。

（3）SSL未配置

在所有使用敏感数据的应用中，SSL都应该被配置以保护数据传输安全。当然你可以在web服务器上配置SSL，但是一旦你的应用服务器设置了合适的SSL key，那么在应用急启用SSL是非常容易的。

?

1 2 3 4 5 6

<security-constraint> ...         <user-data-constraint>                 <transport-guarantee>CONFIDENTIAL</transport-guarantee>         </user-data-constraint> </security-constraint>

(4)未使用安全标示

很多web站点使用SSL进行认证，但是后面或者是阻止非SSL的的后续交互或者使得一部分网站内容仍然可以通过非SSL的访问。这使得会话的cookie（也就是JSESSIONID）容易受到session劫持攻击。要阻止它，cookie可以通过添加安全标志来创建，这确保了浏览器将不会在非SSL环境下传递cookie。

在Servlet规范的旧版本中，没有标准的方式来将JSESSIONID定义为安全的。现在在Servlet3.0中，<cookie-config>元素可以用于确保这个。

?

1 2 3 4 5

<session-config>         <cookie-config>                 <secure>true</secure>         </cookie-config> </session-config>

（5）未使用HttpOnly标志

cookie可以使用HttpOnly标志创建，这将确保cookie不能被客户端脚本访问。这帮助减轻了一些常见的XSS攻击。就像Security标志一样，旧版本的Servlet规范没有提供相应的支持。在Servlet3.0中可以如下的配置它：

?

1 2 3 4 5

<session-config>         <cookie-config>                 <http-only>true</http-only>         </cookie-config> </session-config>

除了Servlet3.0的这种新的标准的方式，旧版本的Tomcat允许在server.xml中使用供应商特定的useHttpOnly属性来启用它。该属性在Tomcat5.5和6中默认是禁用的。在Tomcat7中，该属性默认是启用的。因此即使你在web.xml中将其设置为false，然后部署在tomcat7中，除非你修改了server.xml文件，否则你的JSESSIONID依然是HttpOnly的。

（6） 使用URL参数来跟踪session

Servlet3.0规范中的<tracking-mode>允许你定义JSESSIONID是存储在cookie中还是URL参数中。如果会话ID存储在URL中，那么它可能会被无意的存储在多个地方，包括浏览器历史、代理服务器日志、引用日志和web日志等。暴露了会话ID使得网站被session劫持攻击的几率大增。然而，确保JSESSIONID被存储在cookie中非常容易：

?

1 2 3

<session-config>         <tracking-mode>COOKIE</tracking-mode> </session-config>

（7） 未设置会话超时时间

用户喜欢长时间的会话因为他们很方便。黑客喜欢长时间的会话因为他们有足够的时间来实施像session劫持攻击等。安全和可用性总是会出现冲突。一旦你知道如何使得你的会话存活，你可以按如下方法来配置活动时间：

?

1 2 3

<session-config>         <session-timeout>15</session-timeout> </session-config>

总结

构建和部署安全的应用需要从不同的受益人处获取需求。环境和配置和编码自身一样重要。通过思考这些常见的安全错误配置，希望你可以创建更加安全的应用。