SpringBoot 接口數(shù)據(jù)加解密實戰(zhàn)

這日，剛擼完2行代碼，正準備掏出手機摸魚放松放松，只見老大朝我走過來，并露出一個”善意“的微笑，興偉呀，xx項目有于安全問題，需要對接口整體進行加密處理，你這方面比較有經(jīng)驗，就給你安排上了哈，看這周內(nèi)提測行不...，額，摸摸頭上飄搖著而稀疏的長發(fā)，感覺我愛了。

和產(chǎn)品、前端同學對外需求后，梳理了相關(guān)技術(shù)方案， 主要的需求點如下：

1. 盡量少改動，不影響之前的業(yè)務(wù)邏輯；
2. 考慮到時間緊迫性，可采用對稱性加密方式，服務(wù)需要對接安卓、IOS、H5三端，另外考慮到H5端存儲密鑰安全性相對來說會低一些，故分針對H5和安卓、IOS分配兩套密鑰；
3. 要兼容低版本的接口，后面新開發(fā)的接口可不用兼容；
4. 接口有GET和POST兩種接口，需要都要進行加解密；

需求解析：

1. 服務(wù)端、客戶端和H5統(tǒng)一攔截加解密，網(wǎng)上有成熟方案，也可以按其他服務(wù)中實現(xiàn)的加解密流程來搞；
2. 使用AES放松加密，考慮到H5端存儲密鑰安全性相對來說會低一些，故分針對H5和安卓、IOS分配兩套密鑰；
3. 本次涉及客戶端和服務(wù)端的整體改造，經(jīng)討論，新接口統(tǒng)一加 /secret/ 前綴來區(qū)分

按本次需求來簡單還原問題，定義兩個對象，后面用得著，

用戶類：

@Data
public class User {
    private Integer id;
    private String name;
    private UserType userType = UserType.COMMON;
    @JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss")
    private LocalDateTime registerTime;
}

用戶類型枚舉類：

@Getter
@JsonFormat(shape = JsonFormat.Shape.OBJECT)
public enum UserType {
    VIP("VIP用戶"),
    COMMON("普通用戶");
    private String code;
    private String type;

    UserType(String type) {
        this.code = name();
        this.type = type;
    }
}

構(gòu)造一個簡單的用戶列表查詢示例：

@RestController
@RequestMapping(value = {"/user", "/secret/user"})
public class UserController {
    @RequestMapping("/list")
    ResponseEntity<List<User>> listUser() {
        List<User> users = new ArrayList<>();
        User u = new User();
        u.setId(1);
        u.setName("boyka");
        u.setRegisterTime(LocalDateTime.now());
        u.setUserType(UserType.COMMON);
        users.add(u);
        ResponseEntity<List<User>> response = new ResponseEntity<>();
        response.setCode(200);
        response.setData(users);
        response.setMsg("用戶列表查詢成功");
        return response;
    }
}

調(diào)用：localhost:8080/user/list

查詢結(jié)果如下，沒毛?。?/p>

{
 "code": 200,
 "data": [{
  "id": 1,
  "name": "boyka",
  "userType": {
   "code": "COMMON",
   "type": "普通用戶"
  },
  "registerTime": "2022-03-24 23:58:39"
 }],
 "msg": "用戶列表查詢成功"
}

@ControllerAdvice
@Order(Ordered.HIGHEST_PRECEDENCE)
@Slf4j
public class SecretRequestAdvice extends RequestBodyAdviceAdapter {
    @Override
    public boolean supports(MethodParameter methodParameter, Type type, Class<? extends HttpMessageConverter<?>> aClass) {
        return true;
    }

    @Override
    public HttpInputMessage beforeBodyRead(HttpInputMessage inputMessage, MethodParameter parameter, Type targetType, Class<? extends HttpMessageConverter<?>> converterType) throws IOException {
        //如果支持加密消息，進行消息解密。
        String httpBody;
        if (Boolean.TRUE.equals(SecretFilter.secretThreadLocal.get())) {
            httpBody = decryptBody(inputMessage);
        } else {
            httpBody = StreamUtils.copyToString(inputMessage.getBody(), Charset.defaultCharset());
        }
        //返回處理后的消息體給messageConvert
        return new SecretHttpMessage(new ByteArrayInputStream(httpBody.getBytes()), inputMessage.getHeaders());
    }

    /**
     * 解密消息體
     *
     * @param inputMessage 消息體
     * @return 明文
     */
    private String decryptBody(HttpInputMessage inputMessage) throws IOException {
        InputStream encryptStream = inputMessage.getBody();
        String requestBody = StreamUtils.copyToString(encryptStream, Charset.defaultCharset());
        // 驗簽過程
        HttpHeaders headers = inputMessage.getHeaders();
        if (CollectionUtils.isEmpty(headers.get("clientType"))
                || CollectionUtils.isEmpty(headers.get("timestamp"))
                || CollectionUtils.isEmpty(headers.get("salt"))
                || CollectionUtils.isEmpty(headers.get("signature"))) {
            throw new ResultException(SECRET_API_ERROR, "請求解密參數(shù)錯誤，clientType、timestamp、salt、signature等參數(shù)傳遞是否正確傳遞");
        }

        String timestamp = String.valueOf(Objects.requireNonNull(headers.get("timestamp")).get(0));
        String salt = String.valueOf(Objects.requireNonNull(headers.get("salt")).get(0));
        String signature = String.valueOf(Objects.requireNonNull(headers.get("signature")).get(0));
        String privateKey = SecretFilter.clientPrivateKeyThreadLocal.get();
        ReqSecret reqSecret = JSON.parseObject(requestBody, ReqSecret.class);
        String data = reqSecret.getData();
        String newSignature = "";
        if (!StringUtils.isEmpty(privateKey)) {
            newSignature = Md5Utils.genSignature(timestamp + salt + data + privateKey);
        }
        if (!newSignature.equals(signature)) {
            // 驗簽失敗
            throw new ResultException(SECRET_API_ERROR, "驗簽失敗，請確認加密方式是否正確");
        }

        try {
            String decrypt = EncryptUtils.aesDecrypt(data, privateKey);
            if (StringUtils.isEmpty(decrypt)) {
                decrypt = "{}";
            }
            return decrypt;
        } catch (Exception e) {
            log.error("error: ", e);
        }
        throw new ResultException(SECRET_API_ERROR, "解密失敗");
    }
}

SecretResponseAdvice響應(yīng)加密：

@ControllerAdvice
public class SecretResponseAdvice implements ResponseBodyAdvice {
    private Logger logger = LoggerFactory.getLogger(SecretResponseAdvice.class);

    @Override
    public boolean supports(MethodParameter methodParameter, Class aClass) {
        return true;
    }

    @Override
    public Object beforeBodyWrite(Object o, MethodParameter methodParameter, MediaType mediaType, Class aClass, ServerHttpRequest serverHttpRequest, ServerHttpResponse serverHttpResponse) {
        // 判斷是否需要加密
        Boolean respSecret = SecretFilter.secretThreadLocal.get();
        String secretKey = SecretFilter.clientPrivateKeyThreadLocal.get();
        // 清理本地緩存
        SecretFilter.secretThreadLocal.remove();
        SecretFilter.clientPrivateKeyThreadLocal.remove();
        if (null != respSecret && respSecret) {
            if (o instanceof ResponseBasic) {
                // 外層加密級異常
                if (SECRET_API_ERROR == ((ResponseBasic) o).getCode()) {
                    return SecretResponseBasic.fail(((ResponseBasic) o).getCode(), ((ResponseBasic) o).getData(), ((ResponseBasic) o).getMsg());
                }
                // 業(yè)務(wù)邏輯
                try {
                    String data = EncryptUtils.aesEncrypt(JSON.toJSONString(o), secretKey);
                    // 增加簽名
                    long timestamp = System.currentTimeMillis() / 1000;
                    int salt = EncryptUtils.genSalt();
                    String dataNew = timestamp + "" + salt + "" + data + secretKey;
                    String newSignature = Md5Utils.genSignature(dataNew);
                    return SecretResponseBasic.success(data, timestamp, salt, newSignature);
                } catch (Exception e) {
                    logger.error("beforeBodyWrite error:", e);
                    return SecretResponseBasic.fail(SECRET_API_ERROR, "", "服務(wù)端處理結(jié)果數(shù)據(jù)異常");
                }
            }
        }
        return o;
    }
}

OK， 代碼Demo擼好了，試運行一波：

請求方法：
localhost:8080/secret/user/list

header:
Content-Type:application/json
signature:55efb04a83ca083dd1e6003cde127c45
timestamp:1648308048
salt:123456
clientType:ANDORID

body體:
// 原始請求體
{
 "page": 1,
 "size": 10
}
// 加密后的請求體
{
 "data": "1ZBecdnDuMocxAiW9UtBrJzlvVbueP9K0MsIxQccmU3OPG92oRinVm0GxBwdlXXJ"
}

// 加密響應(yīng)體：
{
    "data": "fxHYvnIE54eAXDbErdrDryEsIYNvsOOkyEKYB1iBcre/QU1wMowHE2BNX/je6OP3NlsCtAeDqcp7J1N332el8q2FokixLvdxAPyW5Un9JiT0LQ3MB8p+nN23pTSIvh9VS92lCA8KULWg2nViSFL5X1VwKrF0K/dcVVZnpw5h227UywP6ezSHjHdA+Q0eKZFGTEv3IzNXWqq/otx5fl1gKQ==",
    "code": 200,
    "signature": "aa61f19da0eb5d99f13c145a40a7746b",
    "msg": "",
    "timestamp": 1648480034,
    "salt": 632648
}

// 解密后的響應(yīng)體：
{
 "code": 200,
 "data": [{
  "id": 1,
  "name": "boyka",
  "registerTime": "2022-03-27T00:19:43.699",
  "userType": "COMMON"
 }],
 "msg": "用戶列表查詢成功",
 "salt": 0
}

OK，客戶端請求加密-》發(fā)起請求-》服務(wù)端解密-》業(yè)務(wù)處理-》服務(wù)端響應(yīng)加密-》客戶端解密展示，看起來沒啥問題，實際是頭天下午花了2小時碰需求，差不多花1小時寫好demo測試，然后對所有接口統(tǒng)一進行了處理，整體一下午趕腳應(yīng)該行了吧，告訴H5和安卓端同學明兒上午聯(lián)調(diào)（不小的大家到這個時候發(fā)現(xiàn)貓膩沒有，當時確實疏忽了，翻了大車......）

次日，安卓端反饋，你這個加解密有問題，解密后的數(shù)據(jù)格式和之前不一樣，仔細一看，擦，這個userType和registerTime是不對勁，開始思考：這個能是哪兒的問題呢？1s之后，初步定位，應(yīng)該是響應(yīng)體的JSON.toJSONString的問題：

String data = EncryptUtils.aesEncrypt(JSON.toJSONString(o)),

WriteEnumUsingToString,
WriteEnumUsingName,
UseISO8601DateFormat

對枚舉類型來說，默認是使用的WriteEnumUsingName(枚舉的Name)， 另一種WriteEnumUsingToString是重新toString方法，理論上可以轉(zhuǎn)換成想要的樣子，即這個樣子：

@Getter
@JsonFormat(shape = JsonFormat.Shape.OBJECT)
public enum UserType {
    VIP("VIP用戶"),
    COMMON("普通用戶");
    private String code;
    private String type;

    UserType(String type) {
        this.code = name();
        this.type = type;
    }

    @Override
    public String toString() {
        return "{" +
                "\"code\":\"" + name() + '\"' +
                ", \"type\":\"" + type + '\"' +
                '}';
    }
}

String data = EncryptUtils.aesEncrypt(JSON.toJSONString(o), secretKey);
 換為：
String data =EncryptUtils.aesEncrypt(new ObjectMapper().writeValueAsString(o), secretKey);

重新運行一波，走起：

{
 "code": 200,
 "data": [{
  "id": 1,
  "name": "boyka",
  "userType": {
   "code": "COMMON",
   "type": "普通用戶"
  },
  "registerTime": {
   "month": "MARCH",
   "year": 2022,
   "dayOfMonth": 29,
   "dayOfWeek": "TUESDAY",
   "dayOfYear": 88,
   "monthValue": 3,
   "hour": 22,
   "minute": 30,
   "nano": 453000000,
   "second": 36,
   "chronology": {
    "id": "ISO",
    "calendarType": "iso8601"
   }
  }
 }],
 "msg": "用戶列表查詢成功"
}

解密后的userType枚舉類型和非加密版本一樣了，舒服了，== 好像還不對，registerTime怎么變成這個樣子了？原本是"2022-03-24 23:58:39"這種格式的，網(wǎng)上有很多解決方案，不過用在我們目前這個需求里面，就是有損改裝了啊，不太可取，遂去Jackson官網(wǎng)上查找一下相關(guān)文檔，當然Jackson也提供了ObjectMapper的序列化配置，重新再初始化配置ObjectMpper對象：

String DATE_TIME_FORMATTER = "yyyy-MM-dd HH:mm:ss";
ObjectMapper objectMapper = new Jackson2ObjectMapperBuilder()
                            .findModulesViaServiceLoader(true)
                            .serializerByType(LocalDateTime.class, new LocalDateTimeSerializer(
                                    DateTimeFormatter.ofPattern(DATE_TIME_FORMATTER)))
                            .deserializerByType(LocalDateTime.class, new LocalDateTimeDeserializer(
                                    DateTimeFormatter.ofPattern(DATE_TIME_FORMATTER)))
                            .build();

轉(zhuǎn)換結(jié)果：

{
 "code": 200,
 "data": [{
  "id": 1,
  "name": "boyka",
  "userType": {
   "code": "COMMON",
   "type": "普通用戶"
  },
  "registerTime": "2022-03-29 22:57:33"
 }],
 "msg": "用戶列表查詢成功"
}

OK，和非加密版的終于一致了，完了嗎？感覺還是可能存在些什么問題，首先業(yè)務(wù)代碼的時間序列化需求不一樣，有"yyyy-MM-dd hh:mm:ss"的，也有"yyyy-MM-dd"的，還可能其他配置思考不到位的，導(dǎo)致和之前非加密版返回數(shù)據(jù)不一致的問題，到時候聯(lián)調(diào)測出來了也麻煩，有沒有一勞永逸的辦法呢？哎，這個時候如果你看過 Spring 源碼的話，就應(yīng)該知道spring框架自身是怎么序列化的，照著配置應(yīng)該就行嘛，好像有點道理，我這里不從0開始分析源碼了。

跟著執(zhí)行鏈路，找到具體的響應(yīng)序列化，重點就是RequestResponseBodyMethodProcessor，

protected <T> void writeWithMessageConverters(@Nullable T value, MethodParameter returnType, ServletServerHttpRequest inputMessage, ServletServerHttpResponse outputMessage) throws IOException, HttpMediaTypeNotAcceptableException, HttpMessageNotWritableException {
        // 獲取響應(yīng)的攔截器鏈并執(zhí)行beforeBodyWrite方法，也就是執(zhí)行了我們自定義的SecretResponseAdvice中的beforeBodyWrite啦
  body = this.getAdvice().beforeBodyWrite(body, returnType, selectedMediaType, converter.getClass(), inputMessage, outputMessage);
  if (body != null) {
      // 執(zhí)行響應(yīng)體序列化工作
   if (genericConverter != null) {
    genericConverter.write(body, (Type)targetType, selectedMediaType, outputMessage);
   } else {
    converter.write(body, selectedMediaType, outputMessage);
   }
    }

進而通過實例化的AbstractJackson2HttpMessageConverter對象找到執(zhí)行序列化的核心方法

-> AbstractGenericHttpMessageConverter:
 
 public final void write(T t, @Nullable Type type, @Nullable MediaType contentType, HttpOutputMessage outputMessage) throws IOException, HttpMessageNotWritableException {
        ...
  this.writeInternal(t, type, outputMessage);
  outputMessage.getBody().flush();
     
    }
 -> 找到Jackson序列化 AbstractJackson2HttpMessageConverter:
 // 從spring容器中獲取并設(shè)置的ObjectMapper實例
 protected ObjectMapper objectMapper;
 
 protected void writeInternal(Object object, @Nullable Type type, HttpOutputMessage outputMessage) throws IOException, HttpMessageNotWritableException {
        MediaType contentType = outputMessage.getHeaders().getContentType();
        JsonEncoding encoding = this.getJsonEncoding(contentType);
        JsonGenerator generator = this.objectMapper.getFactory().createGenerator(outputMessage.getBody(), encoding);

  this.writePrefix(generator, object);
  Object value = object;
  Class<?> serializationView = null;
  FilterProvider filters = null;
  JavaType javaType = null;
  if (object instanceof MappingJacksonValue) {
   MappingJacksonValue container = (MappingJacksonValue)object;
   value = container.getValue();
   serializationView = container.getSerializationView();
   filters = container.getFilters();
  }

  if (type != null && TypeUtils.isAssignable(type, value.getClass())) {
   javaType = this.getJavaType(type, (Class)null);
  }

  ObjectWriter objectWriter = serializationView != null ? this.objectMapper.writerWithView(serializationView) : this.objectMapper.writer();
  if (filters != null) {
   objectWriter = objectWriter.with(filters);
  }

  if (javaType != null && javaType.isContainerType()) {
   objectWriter = objectWriter.forType(javaType);
  }

  SerializationConfig config = objectWriter.getConfig();
  if (contentType != null && contentType.isCompatibleWith(MediaType.TEXT_EVENT_STREAM) && config.isEnabled(SerializationFeature.INDENT_OUTPUT)) {
   objectWriter = objectWriter.with(this.ssePrettyPrinter);
  }
        // 重點進行序列化
  objectWriter.writeValue(generator, value);
  this.writeSuffix(generator, object);
  generator.flush();
    }

那么，可以看出SpringMVC在進行響應(yīng)序列化的時候是從容器中獲取的ObjectMapper實例對象，并會根據(jù)不同的默認配置條件進行序列化，那處理方法就簡單了，我也可以從Spring容器拿數(shù)據(jù)進行序列化啊。SecretResponseAdvice進行如下進一步改造：

@ControllerAdvice
public class SecretResponseAdvice implements ResponseBodyAdvice {

    @Autowired
    private ObjectMapper objectMapper;
     
      @Override
    public Object beforeBodyWrite(....) {
        .....
        String dataStr =objectMapper.writeValueAsString(o);
        String data = EncryptUtils.aesEncrypt(dataStr, secretKey);
        .....
    }
 }

經(jīng)測試，響應(yīng)數(shù)據(jù)和非加密版萬全一致啦，還有GET部分的請求加密，以及后面加解密慘遭跨域問題，后面有空再和大家聊聊。如需本文源碼，可以加我微信分享給大家！