本文所有的demo均放在了github上：
https://github.com/ax1sX/SpringSecurity
SpringConfigTest文件夹为常见配置导致的漏洞demo集合，可下载测试
1. OXM配置
Spring OXM支持Java对象和XML之间映射。Spring OXM并不直接处理XML，而是不同解决方案（如 JAXB、Castor 或 XStream等）的包装器。
JAXB包装器（Jaxb1Marshaller和Jaxb2Marshaller）、Castor包装器（CastorMarshaller）容易受到XXE攻击。而XStream包装器（ XStreamMarshaller）由于不处理DOCTYPE声明块，所以不容易受到XXE攻击，但是可能造成RCE。
JAXB包装器绑定示例——XXE
<bean id="marshaller" class="org.springframework.oxm.jaxb.Jaxb2Marshaller">
<property name="classesToBeBound">
<list>
<value>org.example.jaxb.Order</value>
</list>
</property>
</bean>
这类配置造成的XXE漏洞，对应的漏洞编号为CVE-2013-4152。发现者的博客：http://www.pwntester.com/blog/2013/08/23/springmvc-vulnerable-to-xxe/
XStream包装器绑定示例——XStream RCE
<bean id="marshallingHttpMessageConverter" class="org.springframework.http.converter.xml.MarshallingHttpMessageConverter">
<property name="marshaller" ref="xstreamMarshaller"/>
<property name="unmarshaller" ref="xstreamMarshaller"/>
</bean>
<bean id="xstreamMarshaller" class="org.springframework.oxm.xstream.XStreamMarshaller">
<property name="aliases">
<props>
<prop key="contact">org.pwntester.springserver.ContactImpl</prop>
</props>
</property>
</bean>
发现者博客：http://www.pwntester.com/blog/2013/12/24/more-on-xstream-rce-springmvc-ws/
这里用到了一个类MarshallingHttpMessageConverter，它是HttpMessageConverter接口的实现类之一。这个消息转换接口的应用之一是@ResponseBody。
一个带有@ResponseBody的路由处理方法如下。Spring MVC首先会根据方法参数@RequestBody后的类型选取HttpMessageConverter接口的实现类，以下面的String类型为例，会调用接口实现类StringHttpMessageConverter。然后读取请求中的参数绑定到String类型的变量message中，并执行receive方法。方法执行完成后，由于@ResponseBody注解，将返回值写入到响应报文中。
@RequestMapping(value="/string", method=RequestMethod.POST)
@ResponseBody
public String receive(@RequestBody String message) {
return message;
}
假如方法参数接收的是xml类型数据，并且由XStreamMarshaller转换成Java对象。那么就可以利用XStream反序列化的POC进行RCE攻击。
既然不同类型会有不同的Converters，那么可以在配置中声明要用的Converters。
<mvc:annotation-driven>
<mvc:message-converters>
<bean class="org.springframework.http.converter.xml.MarshallingHttpMessageConverter"/>
<bean class="com.alibaba.fastjson.support.spring.FastJsonHttpMessageConverter"/>
</mvc:message-converters>
</mvc:annotation-driven>
如果没有声明这些Converters，只在配置文件中配置<mvc:annotation-driven/>，那么能使用的就是Spring默认的转换器，包括StringHttpMessageConverter、ByteArrayMessageConverter等
2. Hibernate-Validator配置
在了解这个配置之前，要先了解一个验证数据的规范——JSR 303（后来发展到了JSR 341、JSR 380）。它是 Java EE 6 中的一项子规范，叫做Bean Validation，官方参考实现是Hibernate-Validator。参考：https://beanvalidation.org/1.0/spec/
Hibernate-Validator所需依赖如下
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>5.4.1.Final</version>
</dependency>
官方给的一个简单的例子。JSR303自带了一些约束（Constraint），例如@NotNull、@Pattern(value)、@Size等。下面示例，规定了licensePlate不能为空，并且介于 2 到 14 个字符之间。
public class Car {
@NotNull
@Size(min = 2, max = 14)
private String licensePlate;
}
除了这些规定自带的约束，还可以创建自定义约束，例如验证手机号的@IsMobile。
public class LoginInfo {
@NotNull
@IsMobile
private String mobile;
}
@IsMobile需要有一个对应的接口类
@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER})
@Retention(RUNTIME)
@Documented
@Constraint(validatedBy = {IsMobileValiadator.class}) // 接口实际功能的实现类
public @interface IsMobile {
String message() default "手机号码格式错误"; //通过注解后输出的信息,可以自定义
Class<?>[] groups() default{};
Class<?extends Payload>[] payload() default{};
}
接口功能的具体实现类如下。ConstraintValidator是实现约束行为的接口。
public class IsMobileValiadator implements ConstraintValidator<IsMobile, String> { // 注解名和参数类型
public void initialize(IsMobile constraintAnnotation) {
xxx
}
public boolean isValid(String value, ConstraintValidatorContext context) {
// 实际的校验逻辑
constraintValidatorContext.buildConstraintViolationWithTemplate(s + defaultConstraintMessageTemplate).addConstraintViolation(); // RCE
}
}
如果想在@Controller中触发输入的验证，只需要将参数注释为@Valid。如果想要指定@Valid对应的Validator实例，可以在@Controller的@InitBinder回调中定义，如下。或者在配置文件中用命名空间的方式<mvc:annotation-driven validator="IsMobileValiadator"/>来定义
@Controller
public class MyController {
@InitBinder
protected void initBinder(WebDataBinder binder) {
binder.setValidator(new IsMobileValiadator());
}
@RequestMapping("/login", method=RequestMethod.POST)
public void processInfo(@Valid LoginInfo logininfo) { /* ... */ }
}
自定义约束造成的RCE，发现者博客：https://securitylab.github.com/research/bean-validation-RCE/
需要满足的条件，（1）自定义约束，（2）Controller中绑定了@Valid，对应自定义约束的bean （3）校验逻辑中用到buildConstraintViolationWithTemplate。这样传入的EL表达式会被解析。
后续作者针对Hibernate-Validator配置的修复，也提出了一种绕过方式
https://securitylab.github.com/advisories/GHSL-2020-020-hibernate-validator/
Nexus Repository Manager的一些漏洞：CVE-2018-16621、CVE-2020-10693和CVE-2020-10204。也是因为Hibernate-Validator配置造成的。写Controller的时候需要注意：添加ResponseBody可能出现415， 不添加BindingResult可能出现400。
3. Http-Invoker配置
Spring http-Invoker用于远程调用，服务端配置如下
<bean id="userService" class="org.example.User.UserServiceImpl"/>
<bean name="/UserService" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter">
<property name="serviceInterface" value="org.example.User.IUserService" />
<property name="service" ref="userService" />
</bean>
客户端配置如下
<bean id="userServiceProxy" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
<property name="serviceUrl" value="http://localhost:8080/SpringConfigTest_war_exploded/remote/UserService" />
<property name="serviceInterface" value="org.example.User.IUserService" />
</bean>
服务端的核心在于HttpInvokerServiceExporter，它对应了一个URL路径，一旦访问该路径，就会将请求转换为RemoteInvocation对象，由HttpInvokerServiceExporter对象进行处理，调用指定的方法。将结果封装为RemoteInvocationResult对象并进行序列化。客户端则是要反序列化该对象获取结果。所以存在反序列化漏洞，类似的包括Dubbo的系列漏洞
网友评论