出自：程序猿石头
地址：
https://www.cnblogs.com/leitang/p/13081693.html
之前在某厂的某次项目开发中，项目组同学设计和实现了一个“引以为傲”，额，有点扩张，不过自认为还说得过去的 feature，结果临上线前被啪啪打脸，因为实现过程中因为一行代码（没有标题党，真的是一行代码）带来的安全漏洞让我们丢失了整个服务器控制权（测试环境）。多亏了上线之前有公司安全团队的人会对代码进行扫描，才让这个漏洞被扼杀在摇篮里。
下面我们就一起来看看这个事故，啊，不对，是故事。
我们的项目是一个面向全球用户的 Web 项目，用 SpringBoot 开发。在项目开发过程中，离不开各种异常信息的处理，比如表单提交参数不符合预期，业务逻辑的处理时离不开各种异常信息（例如网络抖动等）的处理。于是利用 SpringBoot 各种现成的组件支持，设计了一个统一的异常信息处理组件，统一管理各种业务流程中可能出现的错误码和错误信息，通过国际化的资源配置文件进行统一输出给用户。
我们的用户遍布全球，为了给各个国家用户比较好的体验会进行不同的翻译。具体而言，实现的效果如下，为了方便理解，以“找回登录密码”这样一个业务场景来进行阐述说明。
假设找回密码时，需要用户输入手机或者邮箱验证码，假设这个时候用户输入的验证码通过后台数据库（可能是redis）对比发现已经过期。在业务代码中，只需要简单的 throw new ErrorCodeException(
ErrorCodes.AUTHCODE_EXPIRED) 即可。具体而言，针对不同国家地区不同的语言看到的效果不一样：
关键信息其实就在于一个 GlobalExceptionHandler，对所有Controller 入口进行 AOP 拦截，根据不同的错误信息，获取相应资源文件配置的 key，并从语言资源文件中读取不同国家的错误翻译信息。
@ControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(BadRequestException.class)
@ResponseBody
public ResponseEntity handle(HttpServletRequest request, BadRequestException e){
String i18message = getI18nMessage(e.getKey(), request);
return ResponseEntity.status(HttpStatus.BAD_REQUEST).body(Response.error(e.getCode(), i18message));
}
@ExceptionHandler(ErrorCodeException.class)
@ResponseBody
public ResponseEntity handle(HttpServletRequest request, ErrorCodeException e){
String i18message = getI18nMessage(e.getKey(), request);
return ResponseEntity.status(HttpStatus.OK).body(Response.error(e.getCode(), i18message));
}
}
不同语言的资源文件示例
private String getI18nMessage(String key, HttpServletRequest request) {
try {
return messageSource.getMessage(key, null, LanguaggeUtils.currentLocale(request));
} catch (Exception e) {
// log
return key;
}
}
还有一种常见的业务场景就是后端接口需要对用户提交的表单进行校验。以“注册用户”这样的场景举例说明， 注册用户时，往往会提交昵称，性别，邮箱等信息进行注册，简单起见，就以这 3 个属性为例。
定义的表单如下：
public class UserRegForm {
private String nickname;
private String gender;
private String email;
}
对于表单的约束，我们有：
对于以上约束，我们只需要在对应的字段上添加如下注解即可。
public class UserRegForm {
@Length(min = 6, max = 20, message = "validate.userRegForm.nickname")
private String nickname;
@Gender(message="validate.userRegForm.gender")
private String gender;
@NotNull
@Email(message="validate.userRegForm.email")
private String email;
}
然后在各个语言资源文件中配置好相应的错误信息提示即可。其中， @Gender 就是一个自定义的注解。
自定义注解的实现主要的其实就是一个自定义注解的定义以及一个校验逻辑。 例如定义一个自定义注解 CustomParam：
@Documented
@Constraint(validatedBy = CustomValidator.class)
@Target({FIELD, METHOD, PARAMETER, ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface CustomParam {
String message() default "name.tanglei.www.validator.CustomArray.defaultMessage";
Class<?>[] groups() default {};
Class<? extends Payload>[] payload() default { };
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({FIELD, METHOD, PARAMETER, ANNOTATION_TYPE})
@interface List {
CustomParam[] value();
}
}
校验逻辑的实现 CustomValidator：
public class CustomValidator implements ConstraintValidator<CustomParam, String> {
@Override
public boolean isValid(String s, ConstraintValidatorContext constraintValidatorContext) {
if (null == s || s.isEmpty()) {
return true;
}
if (s.equals("tanglei")) {
return true;
} else {
error(constraintValidatorContext, "Invalid params: " + s);
return false;
}
}
@Override
public void initialize(CustomParam constraintAnnotation) {
}
private static void error(ConstraintValidatorContext context, String message) {
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这个接口中声明的，看方法名字其实能知道输入参数是一个字符串模板，内部会进行解析替换的（这其实也符合“见名知意”的良好编程习惯）。（教训：大家应该把握好自己写的每一行代码背后实际在做什么。）
/* ......
* @param messageTemplate new un-interpolated constraint message
* @return returns a constraint violation builder
*/
ConstraintViolationBuilder buildConstraintViolationWithTemplate(String messageTemplate);
这个 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注入等等）有所了解，并且要有足够的安全意识（其实有时候研究一些安全问题还挺好玩的）。例如：
如果可能的话，需要对开发者的代码进行漏洞扫描。一些常见的安全漏洞现在应该是有现成的工具支持的。另外，让专业的人做专业的事情，例如要有安全团队，可能你会说你们公司没有不也活的好好的，哈哈，只不过可能还没有被坏人盯上而已，坏人也会考虑到他们的成本和预期收益的，当然这就更加对我们开发者提高了要求。一些敏感权限尽量控制在少部分人手中，配合相应的流程来支撑（不得不说，大公司繁琐的流程还是有一定道理的）。
毕竟我不是专业研究Web安全的，以上说的可能也不一定对，如果你有不同意见或者更好的建议欢迎留言参与讨论。
京公网安备 11010802035086号