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 >

总结

构建和部署安全的应用须要从不一样的受益人处获取需求。环境和配置和编码自身同样重要。经过思考这些常见的安全错误配置，但愿你能够建立更加安全的应用。