Spring Bootインターフェイスのデータ暗号化と復号化は次のように設計される必要があります~

今日の記事では、インターフェイスの暗号化と復号化を含むインターフェイスのセキュリティの問題について説明します。

製品やフロントエンドの学生の外部要求について学生とコミュニケーションを取った後、関連する技術的ソリューションを整理しました。主な要求ポイントは次のとおりです。

• 変更をできるだけ最小限に抑えます。以前のビジネス ロジックに影響します。
• # 時間の緊急性を考慮して、対称暗号化を使用できます。サービスは Android、IOS、および H5 に接続する必要があります。また、H5 側のストレージ キーのセキュリティが比較的低いことを考慮して、H5 と Android および IOS 用に 2 セットのキーが割り当てられており、
• は下位バージョンと互換性がある必要があります。インターフェイスと、後で新しく開発されるインターフェイスは互換性がある必要はありません;
• インターフェイスには GET と POST があります 両方のインターフェイスを暗号化および復号化する必要があります;

要件分析:

• サーバー、クライアント、および H5 は暗号化と復号化を均一に傍受します。インターネット上には成熟したソリューションがあり、他のサービスに実装されている暗号化と復号化のプロセスに従うことができます。
• AES を使用するH5 エンド ストレージ キーのセキュリティが比較的低いことを考慮して、H5 と Android および IOS に 2 つ割り当てられます。キーのセット;
• 今回はクライアントとクライアントの全体的な変換が含まれます。議論の結果、新しいインターフェイスは区別するために /secret/ プレフィックスで統一されました。

この要件に従って単純に復元します。質問、後で使用する 2 つのオブジェクトを定義します。

ユーザー クラス:

@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;
}
}

単純なユーザー リスト クエリの作成例:

@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;
}
}

Call: localhost:8080/user/list

クエリ結果は次のとおりで、何も問題はありません:

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

現在、ControllerAdvice は主にリクエストと応答本文をインターセプトするために使用されます。主に、リクエストを暗号化するための SecretRequestAdvice と応答を暗号化するための SecretResponseAdvice が定義されています (実際の状況はもう少し複雑です。プロジェクトには GET タイプのリクエストもあり、フィルターはさまざまなリクエストの復号化処理に合わせてカスタマイズされています)。

わかりました。インターネット上には、ControllerAdvice の使用例がたくさんあります。中心となる 2 つのメソッドを紹介します。偉い人なら一目でわかると思います。これ以上言う必要はありません。上記のコード:

SecretRequestAdvice リクエストの復号化:

@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, "请求解密参数错误，clientType、timestamp、salt、signature等参数传递是否正确传递");
}

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 レスポンスの暗号化:

@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());
}
// 业务逻辑
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, "", "服务端处理结果数据异常");
}
}
}
return o;
}
}

OK、コード デモの準備ができました。試してみましょう:

请求方法：
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"
}

// 加密响应体：
{
"data": "fxHYvnIE54eAXDbErdrDryEsIYNvsOOkyEKYB1iBcre/QU1wMowHE2BNX/je6OP3NlsCtAeDqcp7J1N332el8q2FokixLvdxAPyW5Un9JiT0LQ3MB8p+nN23pTSIvh9VS92lCA8KULWg2nViSFL5X1VwKrF0K/dcVVZnpw5h227UywP6ezSHjHdA+Q0eKZFGTEv3IzNXWqq/otx5fl1gKQ==",
"code": 200,
"signature": "aa61f19da0eb5d99f13c145a40a7746b",
"msg": "",
"timestamp": 1648480034,
"salt": 632648
}

// 解密后的响应体：
{
 "code": 200,
 "data": [{
"id": 1,
"name": "boyka",
"registerTime": "2022-03-27T00:19:43.699",
"userType": "COMMON"
 }],
 "msg": "用户列表查询成功",
 "salt": 0
}

OK、クライアントが暗号化をリクエスト -> リクエストの開始 -> サーバーの復号化 -> ビジネス処理 -> サーバー応答の暗号化 -> クライアントの復号化表示、問題ないようですが、実際には午後のリクエストに 2 時間を費やしましたデモ テストを作成するのにほぼ 1 時間かかりました。その後、すべてのインターフェイスを統合された方法で処理しました。午後全体を終えて、H5 の生徒と Android の生徒に明日の朝に共同でデバッグするように指示するだけで十分です (決して小さなことではありません) 、この時点で怪しいものは何もないことに誰もが気づきました）、当時の私は確かに不注意で、ひっくり返りました...）

翌日、Android 側から暗号化に問題があると報告され、復号化。復号化されたデータの形式が前と異なります。詳しく見てください。、こすって、この userType と registerTime に何か問題があります。そして、これの何が問題なのでしょうか? と考え始めました。 1 秒後の最初の見解は、応答本文の JSON.toJSONString に問題があるはずだということでした:

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

Debug ブレークポイントのデバッグ. 案の定、JSON.toJSONString(o) の変換に問題がありました。次に、JSON を変換するときに、必要なシリアル化形式を生成するように構成できる詳細プロパティはありますか? FastJson は、シリアル化中にオーバーロード メソッドを提供します。「SerializerFeature」パラメーターの 1 つを見つけて、それについて考えてください。このパラメーターはシリアル化用に構成できます。多くの構成タイプが提供されており、その中で、これらは比較的関連性があると感じます:

WriteEnumUsingToString,
WriteEnumUsingName,
UseISO8601DateFormat

列挙型の場合、デフォルトでは WriteEnumUsingName (列挙型の名前) を使用します。もう 1 つの WriteEnumUsingToString は re-toString メソッドで、理論的には次のように希望するものに変換できます:

@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 + '"' +
'}';
}
}

変換されたデータは文字列型 "{"code":"COMMON", "type":"一般ユーザー"}" です。この方法ではうまくいかないようです。他に良い方法はありませんか?考えた結果、記事の冒頭で定義されている User クラスと UserType クラスを見て、データのシリアル化形式に @JsonFormat をマークしたところ、ふと前に見た記事を思い出しました。デフォルトです。Jackson を使用して実装してください。SecretResponseAdvice のシリアル化メソッドを置き換えます:

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

Wave を再実行して開始します:

{
 "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」という形式でした。インターネット上には多くの解決策がありますが、現在のニーズで使用すると損失を伴う変更となり、お勧めできません。 Jackson 公式 Web サイト 関連ドキュメントの検索 もちろん、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();

変換結果:

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

OK，和非加密版的终于一致了，完了吗？感觉还是可能存在些什么问题，首先业务代码的时间序列化需求不一样，有"yyyy-MM-dd hh:mm:ss"的，也有"yyyy-MM-dd"的，还可能其他配置思考不到位的，导致和之前非加密版返回数据不一致的问题，到时候联调测出来了也麻烦，有没有一劳永逸的办法呢？哎，这个时候如果你看过 Spring 源码的话，就应该知道spring框架自身是怎么序列化的，照着配置应该就行嘛，好像有点道理，我这里不从0开始分析源码了。

跟着执行链路，找到具体的响应序列化，重点就是RequestResponseBodyMethodProcessor，

protected <T> void writeWithMessageConverters(@Nullable T value, MethodParameter returnType, ServletServerHttpRequest inputMessage, ServletServerHttpResponse outputMessage) throws IOException, HttpMediaTypeNotAcceptableException, HttpMessageNotWritableException {
// 获取响应的拦截器链并执行beforeBodyWrite方法，也就是执行了我们自定义的SecretResponseAdvice中的beforeBodyWrite啦
body = this.getAdvice().beforeBodyWrite(body, returnType, selectedMediaType, converter.getClass(), inputMessage, outputMessage);
if (body != null) {
// 执行响应体序列化工作
 if (genericConverter != null) {
genericConverter.write(body, (Type)targetType, selectedMediaType, outputMessage);
 } else {
converter.write(body, selectedMediaType, outputMessage);
 }
}

进而通过实例化的AbstractJackson2HttpMessageConverter对象找到执行序列化的核心方法

-> 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容器中获取并设置的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在进行响应序列化的时候是从容器中获取的ObjectMapper实例对象，并会根据不同的默认配置条件进行序列化，那处理方法就简单了，我也可以从Spring容器拿数据进行序列化啊。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);
.....
}
 }

经测试，响应数据和非加密版万全一致啦，还有GET部分的请求加密，以及后面加解密惨遭跨域问题，后面有空再和大家聊聊。

以上がSpring Bootインターフェイスのデータ暗号化と復号化は次のように設計される必要があります~の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。