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

web.xml 文件中的一些常见的安全错误配置。

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

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

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

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

<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”角色的用户访问。

<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 是非常容易的。

<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>元素可以用于确保这个。

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

(5）未使用 HttpOnly 标志

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

<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 中非常容易：

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

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

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

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

总结

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