当前位置: 首页 > news >正文

优雅的处理 API 接口敏感数据加解密(方案详解)

  • 一、背景与目标

  • 二、方案设计

    • 对称加密、非对称加密、哈希算法、验签算法

    • HTTPS原理概述

    • 微信支付加解密原理

    • 接口加解密设计思路

  • 三、技术实现

  • 四、常见问题

  • 五、安全性分析


一、背景与目标

随着网络技术的快速发展,数据安全问题日益突出。为了防止爬虫、防请求篡改、防请求重放,以及验证数据完整性,本方案结合HTTPS原理和微信支付加解密设计,通过对称加密、非对称加密、签名等技术,为API接口提供加解密设计和落地。

二、方案设计

对称加密、非对称加密、哈希算法、验签算法

  • 对称加密:采用相同的密钥进行加密和解密。具有加密速度快、计算量小的优点,但密钥的安全传输是问题。在本方案中,对称加密主要用于数据的实际加密传输。

  • 非对称加密:使用一对密钥(公钥和私钥)进行加密和解密。公钥用于加密数据,私钥用于解密数据。非对称加密可以确保密钥的安全传输,但加密速度较慢,不适合长文本加密。在本方案中,非对称加密主要用于对称密钥的加密。

  • 哈希算法:无论用户输入什么长度的原始数据,经过计算后输出的密文都是固定长度的,只要原数据稍有改变,输出的“摘要”便完全不同

  • 签名算法:一般指的是,通过私钥对数据进行签名,然后通过公钥对数据进行验签

HTTPS原理概述

HTTPS(Hypertext Transfer Protocol Secure)是一种通过计算机网络进行安全通信的传输协议。它利用SSL/TLS协议在HTTP应用层进行通信加密,通过证书进行身份验证,从而确保数据传输的安全性和完整性。

微信支付加解密原理

  • 请求签名:通过商户API证书私钥,对每一次请求进行RSA-SHA256签名,微信支付进行验签

  • 回调验签:微信支付通过平台证书私钥,对每一次回调进行RSA-SHA256签名,商户接收到请求后,通过平台正式公钥进行验签

  • 回调解密:商户根据配置的apiV3密钥,对加密数据进行AES-256-GCM解密

接口加解密设计思路

  • 密钥交换:客户端使用服务端的公钥对对称加密的密钥进行加密,然后将密文密钥发送给服务端。服务端使用自己的私钥解密得到对称加密的明文密钥。

  • 数据加密:客户端使用对称加密的明文密钥对接口数据进行加密,然后发送给服务端。服务端使用相同的对称加密密钥对数据进行解密。

  • 数据哈希(签名):在数据发送前,客户端计算数据的哈希值,并将哈希值作为数据的一部分发送给服务端。服务端收到数据后,使用相同的算法计算哈希值,并与客户端发送的哈希值进行比较,以验证数据的完整性。

  • 数据有效性校验:在数据发送前,客户端将当前时间作为数据的一部分发送给服务端。服务端收到数据后,解密得到参数中的时间,并与服务端当前时间进行比较,以验证请求是否过期,防止请求重放。

三、技术实现

1、密钥生成与管理:

通过工具生成非对称密钥对,服务端负责保管私钥。(客户端也可以定期从服务端获取公钥(传输过程中有泄露的风险),并保存到LocalStorage。)

2、加密算法选择:

对称加密算法可选用常用的AES,非对称加密算法可选用常用的RSA。哈希算法可选用SHA-256、MD5,签名算法可选用RSA-SHA256等。根据Hutool加密算法如下:

// 对称密钥 String key = "key"; AES aes = SecureUtil.aes(key.getBytes()); // 加密 String ciphertext = aes.encryptBase64(content); // 解密 String result = aes.decryptStr(ciphertext); // 非对称公钥 String publicKey = "xxxxxxx"; // 对称密钥 String key = "key"; RSA rsa = new RSA(null, publicKey); // 对对称密钥进行加密 String ciphertextKey = rsa.encryptBase64(key, KeyType.PublicKey); // 非对称私钥 String privateKey = "xxxxxxx"; RSA rsa2 = new RSA(privateKey, null); // 对加密的对称密钥进行解密 String key = rsa2.encryptBase64(ciphertextKey, KeyType.PrivateKey); String data = "测试"; Digester sha256 = new Digester(DigestAlgorithm.SHA256); System.out.println(sha256.digestHex(data)); // 暂不考虑 String publicKey = "xxxxx"; String privateKey = "xxxxx"; String data = "测试"; Sign privateSign = SecureUtil.sign(SignAlgorithm.SHA256withRSA, privateKey, null); String sign = new String(Base64.getEncoder().encode(privateSign.sign(data))); System.out.println("签名:" + sign); Sign publicSign = SecureUtil.sign(SignAlgorithm.SHA256withRSA, null, publicKey); System.out.println(publicSign.verify(data.getBytes(), Base64.getDecoder().decode(sign.getBytes())));
3、签名规则:

等queryString和body参数加密后,将queryString、时间戳、明文对称密钥、body参数按顺序进行拼接,然后通过SHA256算法进行哈希得到签名sign,然后将sign放在header中进行传递

4、参数传递:
  • ek(encryt-key):xxxxxxx(非对称加密后的对称密钥)

  • ts:xxxxxxx(时间戳)

  • sign:xxxxxxx

将请求参数queryString拼成"param1=value1&param2=value2"格式

queryString进行对称加密,得到"ciphertext=xxxxx",并重新拼接到url后面

query参数可以参考GET请求

body参数可以通过对称加密得到base64密文,直接用body进行传输

例如:

url?ciphertext=xxxxx body:xxxxxxxx
5、后端处理:
  1. 请求有效验证:获取header中ts参数,得到时间戳并判断时间戳是否超过一定时间;

  2. 解密对称密钥:通过私钥解密header中的ek参数,得到明文的对称密钥key;

  3. 验签:将queryString、时间戳、明文对称密钥、body参数按顺序进行拼接,然后通过SHA256算法进行哈希得到签名sign,与header中的sign做比较;

  4. 解密参数:通过明文对称密钥,分别解密queryString、body参数;

  5. 加密响应结果:请求完成后,将响应结果通过对称加密得到base64密文,并返回给客户端

四、常见问题

Q:为什么需要参考HTTPS来设计接口加解密?

A:HTTPS结合了对称加密和非对称加密,安全性更高,同时也能满足效率要求

Q:如果只使用对称加密有什么问题?

A:客户端是不安全的,很容易暴露密钥,只要一旦暴露,加密就形同虚设

Q:如果只使用非对称加密有什么问题?

A:

  • 非对称加密不支持超长文本加密(RSA只支持117字节);

  • 非对称加密效率太慢

Q:接口参数已经加密了,是否还有必要签名?

A:有必要,生产环境不是每一个接口都需要加密的。但是每一个接口都需要防篡改、防重放

Q:签名算法为什么没有采用RSA-SHA256?

A:

  • RSA-SHA256签名算法只能私钥签名,公钥验签。

  • 客户端存的是公钥,如果要采用该算法,需要再定义一套非对称密钥,加重了维护成本。

  • 现在采用哈希算法SHA256进行模拟签名,其中混入了明文的对称密钥,也可以防止模拟签名

Q:用了对称和非对称混合加密,非对称公钥保存在客户端,还是有可能泄露,怎么保证安全?

A:

  • 前端代码压缩、混淆;

  • 公钥不要直接写到代码里,分段、加密保存;

  • 即使公钥暴露了,对称密钥每次都是新生成的,抓包也拿不到本次请求的对称密钥,也就没有办法对结果解密

Q:对称和非对称同时使用的话,怎么保证加解密的效率?

A:请求参数和响应结果实际还是通过对称加密,非对称只会对对称密钥进行加解密,所以效率和对称加密差不多4

Q:该方案是否是绝对安全?如果不是,是否有绝对安全的加解密方案?

A:

  • 不是,如果客户端被破解了,用户可以模拟客户端发起请求

  • 暂时没有,客户端对于互联网都是透明的,只要客户端被破解了,都可以模拟客户端发起请求

五、安全性分析

本方案结合对称加密和非对称加密的优点,既保证了数据传输的安全性,又提高了加密解密的效率。但是需要考虑客户端公钥的安全性。

防篡改:请求参数都进行了签名,只要客户端公钥不泄露,无法修改请求参数;

防爬虫:请求参数进行了签名和加密,无法模拟客户端请求;响应结果进行了加密,即使抓包拿到了结果,也无法进行解密

防重放:请求头中引入时间戳,并且时间戳也进行了验签,可以防止篡改,每次服务端接收到请求都会验证时间戳的有效性。(短时间内的重放暂时阻止不了,可以考虑在后端在缓存进行验证,但目前业务用不上)

http://www.cnnetsun.cn/news/483868.html

相关文章:

  • 《Light: Science Applications》超表面偏振态与偏振度完全独立控制新范式
  • Qwen3Guard-Gen-8B可用于简历生成内容真实性核查
  • Glitch项目内容审核:Qwen3Guard-Gen-8B保护开发者社区生态
  • Java程序员如何备战金三银四?
  • 三菱FX5U七轴标准程序解析
  • 收藏!小白程序员必看:大语言模型核心原理全解析(从ChatGPT到Transformer)
  • 2.34 二手车价格预测完整案例:特征工程、模型训练、调参全流程
  • 2.46 AI大赛实战:资金流入流出预测,从数据到模型完整解决方案
  • AI Agent正在消灭编程岗位?真相是:这是程序员的最好时代!小白开发者如何抓住这波AI红利?
  • 【深度干货】AI Agent的“六神合体“术:从感知到优化的完整闭环,小白也能懂
  • 中国团队打造音乐MV制作新利器:让任何人都能拍出专业级音乐视频
  • 2.36 模型融合原理与技巧:Stacking、Blending,提升模型效果的最后一步
  • MATLAB海洋声传播仿真设计与实现
  • 性能测试数据生成实用指南
  • AI智慧司牧服务系统:打造草原上的“千里眼”与“数字牧羊人”
  • 基于拥挤距离的多目标粒子群优化算法(MO-PSO-CD)详解
  • 类型断言:强制类型转换的技巧
  • AG 的“石器时代”结束了!读 PDF 别再瞎折腾工具链,RAG-Anything + Milvus 一招制胜!
  • 从“提示词奴隶“到“AI架构师“:Anthropic上下文工程大揭秘,小白也能驯服大模型!
  • 【Linux命令大全】003.文档编辑之pico命令(实操篇)
  • 基于STM32的运动信息检测装置设计与实现
  • 无人值守智能污水处理控制系统:威纶通触摸屏与西门子PLC协同运行,真实工程项目稳定运行一年多供...
  • 今日头条视频下载方法汇总 高清无水印 (2026 最新实测)
  • 2026全新版Java面试八股文.pdf出炉, 简直把所有 Java 知识面试题写出来了
  • 硕士论文过审第一步:paperzz 论文查重功能,怎么帮你避开重复率雷区?
  • 【高录用、快见刊】第二届能源工程与污染治理国际学术会议(EEPC 2026)
  • 什么是Keychain
  • 数据库性能测试最佳实践
  • 无法修补的漏洞:PS5_BootROM密钥遭泄露,索尼安全防线崩塌
  • 公司趁我下班之后偷看我电脑,看到我电脑里有git拉的代码,说我干私活要把我开了。。