一行代码引来的安全漏洞，就让我们丢失了整个服务器的控制权

之前在某厂的某次项目开发中，项目组同学设计和实现了一个“引以为傲”，额，有点扩张，不过自认为还说得过去的 feature，结果临上线前被啪啪打脸，因为实现过程中因为一行代码（没有标题党，真的是一行代码）带来的安全漏洞让我们丢失了整个服务器控制权（测试环境）。多亏了上线之前有公司安全团队的人会对代码进行扫描，才让这个漏洞被扼杀在摇篮里。

下面我们就一起来看看这个事故，啊，不对，是故事。

背景说明

我们的项目是一个面向全球用户的 Web 项目，用 SpringBoot 开发。在项目开发过程中，离不开各种异常信息的处理，比如表单提交参数不符合预期，业务逻辑的处理时离不开各种异常信息（例如网络抖动等）的处理。于是利用 SpringBoot 各种现成的组件支持，设计了一个统一的异常信息处理组件，统一管理各种业务流程中可能出现的错误码和错误信息，通过国际化的资源配置文件进行统一输出给用户。

统一错误信息配置管理

我们的用户遍布全球，为了给各个国家用户比较好的体验会进行不同的翻译。具体而言，实现的效果如下，为了方便理解，以“找回登录密码”这样一个业务场景来进行阐述说明。

假设找回密码时，需要用户输入手机或者邮箱验证码，假设这个时候用户输入的验证码通过后台数据库（可能是Redis）对比发现已经过期。在业务代码中，只需要简单的 throw new ErrorCodeException(
ErrorCodes.AUTHCODE_EXPIRED) 即可。具体而言，针对不同国家地区不同的语言看到的效果不一样：

• 中文用户看到的提示就是“您输入的验证码已过期，请重新获取”；
• 欧美用户看到的效果是“The verification code you input is expired, …”；
• 德国用户看到的是：“Der von Ihnen eingegebene Verifizierungscode ist abgelaufen, bitte wiederholen” 。（我瞎找的翻译，不一定准）
• ……

统一错误信息配置管理代码实现

关键信息其实就在于一个 GlobalExceptionHandler，对所有Controller 入口进行 AOP 拦截，根据不同的错误信息，获取相应资源文件配置的 key，并从语言资源文件中读取不同国家的错误翻译信息。

@ControllerAdvice
publicclassGlobalExceptionHandler{

@ExceptionHandler(BadRequestException.class)
@ResponseBody
publicResponseEntityhandle(HttpServletRequestrequest,BadRequestExceptione){
Stringi18message=getI18nMessage(e.getKey(),request);
returnResponseEntity.status(HttpStatus.BAD_REQUEST).body(Response.error(e.getCode(),i18message));
}

@ExceptionHandler(ErrorCodeException.class)
@ResponseBody
publicResponseEntityhandle(HttpServletRequestrequest,ErrorCodeExceptione){
Stringi18message=getI18nMessage(e.getKey(),request);
returnResponseEntity.status(HttpStatus.OK).body(Response.error(e.getCode(),i18message));
}
}

不同语言的资源文件示例

privateStringgetI18nMessage(Stringkey,HttpServletRequestrequest){
try{
returnmessageSource.getMessage(key,null,LanguaggeUtils.currentLocale(request));
}catch(Exceptione){
//log
returnkey;
}
}

基于注解的表单校验（含自定义注解）

还有一种常见的业务场景就是后端接口需要对用户提交的表单进行校验。以“注册用户”这样的场景举例说明， 注册用户时，往往会提交昵称，性别，邮箱等信息进行注册，简单起见，就以这 3 个属性为例。

定义的表单如下：

publicclassUserRegForm{
privateStringnickname;
privateStringgender;
privateStringemail;
}

对于表单的约束，我们有：

• 昵称字段：“nickname” 必填，长度必须是 6 到 20 位；
• 性别字段：“gender” 可选，如果填了，就必须是“Male/Female/Other/”中的一种。说啥，除了男女还有其他？对，是的。毕竟全球用户嘛，你去看看非死不可，还有更多。
• 邮箱： “email”，必填，必须满足邮箱格式。

对于以上约束，我们只需要在对应的字段上添加如下注解即可。

publicclassUserRegForm{
@Length(min=6,max=20,message="validate.userRegForm.nickname")
privateStringnickname;

@Gender(message="validate.userRegForm.gender")
privateStringgender;

@NotNull
@Email(message="validate.userRegForm.email")
privateStringemail;
}

然后在各个语言资源文件中配置好相应的错误信息提示即可。其中， @Gender 就是一个自定义的注解。

基于含自定义注解的表单校验关键代码

自定义注解的实现主要的其实就是一个自定义注解的定义以及一个校验逻辑。 例如定义一个自定义注解 CustomParam：

@Documented
@Constraint(validatedBy=CustomValidator.class)
@Target({FIELD,METHOD,PARAMETER,ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
public@interfaceCustomParam{
Stringmessage()default"name.tanglei.www.validator.CustomArray.defaultMessage";

Class<?>[]groups()default{};
Class<?extendsPayload>[]payload()default{};

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({FIELD,METHOD,PARAMETER,ANNOTATION_TYPE})
@interfaceList{
CustomParam[]value();
}
}

校验逻辑的实现 CustomValidator：

publicclassCustomValidatorimplementsConstraintValidator<CustomParam,String>{
@Override
publicbooleanisValid(Strings,ConstraintValidatorContextconstraintValidatorContext){
if(null==s||s.isEmpty()){
returntrue;
}
if(s.equals("tanglei")){
returntrue;
}else{
error(constraintValidatorContext,"Invalidparams:"+s);
returnfalse;
}
}

@Override
publicvoidinitialize(CustomParamconstraintAnnotation){
}

privatestaticvoiderror(ConstraintValidatorContextcontext,Stringmessage){
context.disableDefaultConstraintViolation();
context.buildConstraintViolationWithTemplate(message).addConstraintViolation();
}
}

上面例子只为了阐述说明问题，其中校验逻辑没有实际意义，这样，如果输入参数不满足条件，就会明确提示用户输入的哪个参数不满足条件。例如输入参数 xx，则会直接提示：Invalid params: xx。

这个跟第一部分的处理方式类似，因为现有的 validator 组件实现中，如果违反相应的约束也是一种抛异常的方式实现的，因此只需要在上述的 GlobalExceptionHandler中添加相应的异常信息即可，这里就不详述了。 这不是本文的重点，这里就不详细阐述了。

场景重现

一切都显得很完美，直到上线前代码提交至安全团队扫描，就被“啪啪打脸”，扫描报告反馈了一个严重的安全漏洞。而这个安全漏洞，属于很高危的远程代码执行漏洞。

用前文提到的自定义 Validator，输入的参数用： “1+1=${1+1}”，看看效果：

太 TM 神奇了，居然帮我运算出来了，返回 "message": "Invalid params: 1+1=2"。

问题就出现在实现自定义注解进行校验的这行代码（如下图所示）：

其实，最开始的时候，这里直接返回了“Invalid params”，当初为了更好的用户体验，要明确告诉用户哪个参数没有通过校验，因此在输出的提示上加上了用户输入的字段，也就是上面的"Invalid params: " + s，没想到，这闯了大祸了（回过头来想，感觉这里没必要这么详细啊，因为前端已经有相应的校验了，正常情况下回拦住，针对不守规矩的用非常规手段来的接口请求，直接返回校验不通过就行了，毕竟不是对外提供的 OpenAPI 服务）。

仔细看，这个方法实际上是
ConstraintValidatorContext这个接口中声明的，看方法名字其实能知道输入参数是一个字符串模板，内部会进行解析替换的（这其实也符合“见名知意”的良好编程习惯）。（教训：大家应该把握好自己写的每一行代码背后实际在做什么。）

/*......
*@parammessageTemplatenewun-interpolatedconstraintmessage
*@returnreturnsaconstraintviolationbuilder
*/
ConstraintViolationBuilderbuildConstraintViolationWithTemplate(StringmessageTemplate);

这个 case，源码调试进去之后，就能跟踪到执行翻译阶段，在如下方法中：
org.hibernate.validator.messageinterpolation.AbstractMessageInterpolator.interpolateMessage。

再往后，就是表达式求值了。 [图片上传失败…(image-9239c-1591863495667)]

以为就这样就完了吗？

刚开始感觉，能帮忙算简单的运算规则也就完了吧，你还能把我怎么样？其实这个相当于暴露了一个入口，支持用户输入任意 EL 表达式进行执行。网上通过关键字 “SpEL表达式注入漏洞” 找找，就能发现事情并没有想象中那么简单。

我们构造恰当的 EL 表达式（注意各种转义，下文的输入参数相对比较明显在做什么了，实际上还有更多黑科技，比如各种二进制转义编码啊等等），就能直接执行输入代码，例如：可以直接执行命令，“ls -al”， 返回了一个 UNIXProcess 实例，命令已经被执行过了。

比如，我们执行个打开计算器的命令，搞个计算器玩玩~

我录制了一个动图，来个演示可能更生动一些。

这还得了吗？这相当于提供了一个 webshell 的功能呀，你看想运行啥命令就能运行啥命令，例如 ping 本人博客地址（ping www.tanglei.name），下面动图演示一下整个过程（从运行 ping 到 kill ping）。

岂不是直接创建一个用户，然后远程登录就可以了。后果很严重啊，别人想干嘛就干嘛了。

我们跟踪下对应的代码，看看内部实现，就会“恍然大悟”了。

经验教训

幸亏这个漏洞被扼杀在摇篮里，否则后果还真的挺严重的。通过这个案例，我们有啥经验和教训呢？那就是作为程序员，我们要对每一行代码都保持“敬畏”之心。也许就是因为你的不经意的一行代码就带来了严重的安全漏洞，要是不小心被坏人利用，轻则……重则……（自己想象吧）

此外，我们也应该看到，程序员需要对常见的安全漏洞（例如XSS/CSRF/SQL注入等等）有所了解，并且要有足够的安全意识（其实有时候研究一些安全问题还挺好玩的）。例如：

• 用户权限分离：运行程序的用户不应该用 root，例如新建一个“web”或者“www”之类的用户，并设置该用户的权限，比如不能有可执行 xx 的权限之类的。本文 case，如果权限进行了分离（遵循最小权限原则），应该也不会这么严重。（本文就刚好是因为是测试环境，所以没有强制实施）
• 任何时候都不要相信用户的输入，必须对用户输入的进行校验和过滤，又特别是针对公网上的应用。
• 敏感信息加密保存。退一万步讲，假设攻击者攻入了你的服务器，如果这个时候，你的数据库账户信息等配置都直接明文保存在服务器中。那数据库也被拖走了。

如果可能的话，需要对开发者的代码进行漏洞扫描。一些常见的安全漏洞现在应该是有现成的工具支持的。另外，让专业的人做专业的事情，例如要有安全团队，可能你会说你们公司没有不也活的好好的，哈哈，只不过可能还没有被坏人盯上而已，坏人也会考虑到他们的成本和预期收益的，当然这就更加对我们开发者提高了要求。一些敏感权限尽量控制在少部分人手中，配合相应的流程来支撑（不得不说，大公司繁琐的流程还是有一定道理的）。

毕竟我不是专业研究Web安全的，以上说的可能也不一定对，如果你有不同意见或者更好的建议欢迎留言参与讨论。