在给系统做安全检测的过程中,发现了一个低危安全性问题,检测到目标服务器启用了OPTIONS方法。
OPTIONS方法是用于请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项。通过这个方法,客户 端可以在采取具体资源请求之前,决定对该资源采取何种必要措施,或者了解服务器的性能。OPTIONS方法可能会暴露一些敏感 信息,这些信息将帮助攻击者准备更进一步的攻击。
解决方案一:单个项目生效
在项目中的web.xml配置,放在web.xml最后添加如下内容:
<!-- 关闭不安全的HTTP方法 -->
<security-constraint>
<web-resource-collection>
<web-resource-name>http method security</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint/>
</security-constraint>
解决方案二:Tomcat中所有项目生效
在Tomcat服务器的web.xml上配置,路径tomcat/conf/web.xml。修改内容如下:
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
version="3.1">
<!-- 以上是tomcat中本身存在,下面是新添加内容-->
<security-constraint>
<web-resource-collection>
<web-resource-name>http method security</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>HEAD</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint/>
</security-constraint>
一般在Tomcat服务器中配置,单个项目配置本地调试没有问题,部署到Tomcat上依然会出现问题,还未找到原因。下面我们来看下配置前后的效果对比:
配置前:
配置后:
还是可以明显看到问题所在的,配置后禁止了页面信息的返回。配置前无信息返回是因为前端框架用的VUE,如果是JSP则会返回页面信息,这样就增加了安全风险。
下面对上面用到的配置元素做一个简单介绍:
<security-constraint>
中的子元素<http-method>
是可选的,如果没有<http-method>
元素,这表示将禁止所有 HTTP 方法访问相应的资源。<auth-constraint>
子元素,其内容为空,表示所有身份的用户都被禁止访问相应的资源。如果没<auth-constraint>
子元素,配置实际上是不起作用的。
还有一个<login-config>
,这里我们没有用到,它和<security-constraint>
同级,配合<auth-constraint>
使用,当访问服务器中受保护的资源时,容器管理的验证方法可以控制用户身份的确认方式。Tomcat支持四种容器管理的安全防护:
- BASIC:通过HTTP验证,需要提供base64编码文本的用户口令
- DIGEST:通过HTTP验证,需要提供摘要编码字符串的用户口令
- FORM:在网页的表单上要求提供密码