这是一个创建于 591 天前的主题，其中的信息可能已经有所发展或是发生改变。
Spring Boot 项目，对于加密传输有所疑惑。目前我的实践是用 SM4 在后端加密，然后将加密数据传输给前端，前端根据密钥来解密展示。这样做虽然能够解决传输过程中的安全问题，但是我目前的实践方案涉及到密钥存储在 js 中，这样如果 js 的密钥暴漏了，其实没有解决安全风险问题。请问各位前辈是如何处理此类问题的？
 |
1
xiaohundun 2023-04-04 10:56:35 +08:00
起码把问题写清楚。。。。
|
 |
2
cynical666 OP @xiaohundun 抱歉，刚操作失误了，现在问题已编辑。
|
 |
3
cogear 2023-04-04 11:01:13 +08:00
HTTPS 是 Http + TLS 的组合，一般不是开发考虑的问题，后端应用正常接受 Http 请求，网关那边会做 Https 加密解密，并把 http 请求转发到后端应用。
如果是自己部署小项目，用 Nginx 做个 Https 反代就行 |
|
4
xiaohundun 2023-04-04 11:04:36 +08:00
@cynical666 解决传输过程中的安全问题，用 https
|
|
5
cynical666 OP |
 |
6
hhjswf 2023-04-04 11:17:31 +08:00
你是说加密报文参数？
|
|
7
cynical666 OP @hhjswf 是的
|
 |
8
zbatman 2023-04-04 11:21:33 +08:00
为啥不希望不加密就放到报文响应体中呢？
|
 |
9
yankebupt 2023-04-04 11:21:37 +08:00
斗鱼 P2P 的直播流是非对称加密的，客户端拿到了解密密钥也没用，但仅仅是为了防篡改（因为途径了第三方用户）。
上 WASM 解密可以的，就是有点流氓。 |
 |
10
flush9f 2023-04-04 11:27:06 +08:00
如果有两侧都知道的密钥，可以 challenge 鉴定后用这个 key 做 master key 来加密，不然就只有非对称加密了
|
 |
11
zhywang 2023-04-04 11:35:18 +08:00  1
先使用非对称加密算法完成密钥交换，然后再使用对称算法用密钥对业务数据进行加密，简单过程大概这样：
1. 客户端（ js ）内置非对称加密公钥，在握手阶段，客户端随机生成密钥的配置，将这个配置用公钥加密后发给服务端。这样即使加密后的内容被截获也无法破解，因为私钥在服务端存储。 2. 服务端用私钥解出密钥配置后，用对称加密算法和服务器端提供的密钥加密响应。 3. 客户端对响应进行解密，确认服务器端已经成功配置，后续使用对称加密进行通信。 之所以搞这么麻烦，是因为一般来说非对称加密只用来处理小数据段，加密大量数据时效率很低而且也不容易解决双向加密需求。 |
 |
13
leonshaw 2023-04-04 11:51:38 +08:00
前端要解密就没有完美的方法，做好代码混淆
|
 |
14
kaedeair 2023-04-04 11:57:26 +08:00
只要人家能用 debugger 任何形式的前端加密解密就不安全
|
 |
15
litchinn 2023-04-04 11:58:09 +08:00 1
WASM 好像确实可以增加被破解的难度
没有绝对的安全，这个问题首先要考虑你想要什么样的安全级别，和你的实施成本，当你对你的浏览器本身产生不信任的时候那基本啥办法也没用，只有不给前端这些数据，逻辑处理全放在后端，当你信任浏览器时那么 https 就够了，楼上给出的例如非对称加密交换一个对称加密的密钥然后通讯也就是把 https 的流程走了一遍。 如果你只是不想让人凭肉眼 f12 就看到数据，那你多转几次 base64 就能达到目的，甚至不需要加密 |
 |
16
darkengine 2023-04-04 12:01:22 +08:00
其实解决了传输的问题就够了，展示在前端的东西你怎么藏？
|
 |
17
Huelse 2023-04-04 12:37:07 +08:00
前端加密主要保证的是时效性，即使客户端拿到密钥了也不能一直用于揭秘获取正确数据
|
 |
18
byte10 2023-04-04 14:35:59 +08:00
参考下 微信 小程序的做法吧，用户会话的的 session_key 就是作为对称密匙，每次加密就是用这个 session_key 进行加密的，这算是比较常见做法。 客户端是每次在 用户登录后 得到这个加密钥匙。
|
 |
19
zpfhbyx 2023-04-04 14:37:12 +08:00
js 图片隐写加密
|
|
21
zhywang 2023-04-04 15:37:02 +08:00
@litchinn 正解，能采用加密保证安全的前提是浏览器运行环境（包括浏览器、操作系统、甚至硬件）安全，一般在根证书可信的情况下，https 加密可以满足绝大多数场景
|
 |
22
lysS 2023-04-04 15:51:31 +08:00
tls 双向加密呗，client 必须要安装你提供的证书才能访问
|
 |
23
swqslwl 2023-04-04 16:30:33 +08:00
要用国密加密套件吗，是的话用 GMSSL 。
|
 |
24
cnbattle 2023-04-04 16:40:35 +08:00
@zhywang 客户端公钥泄露，一样可以在客户端显示前 拦截或篡改相关数据，没有解决 lz 的担心，客户端的风险问题
个人看法，lz 的这个担忧，没有完美的方案， 只是增加门槛，在成本和效果间选择取舍，比如你的说方案，wasm 方案，或软硬件可信设备的方案等 |
 |
25
yule111222 2023-04-04 16:45:54 +08:00
你可以把前端需要这些敏感数据处理的业务逻辑移到后端
|
|
26
yule111222 2023-04-04 16:46:30 +08:00
前端要处理的应该只是交互逻辑，这些东西需要的数据本来就应该可以完全暴露出去的
|
|
27
zhywang 2023-04-04 16:47:52 +08:00
@cnbattle 我说的方案对付一般的中间人攻击是没问题的。同意你的观点，在安全问题上没有完美方案，只是增加门槛（大力出奇迹各种加密算法也不是不能破解，更别说不安全的软件硬件环境，哈哈）
|
 |
28
adoal 2023-04-04 16:50:32 +08:00
只要“在 UI 里需要拿到真实数据才能展示想要的结果”成立，加密就没用，毕竟总有一个你不可控而用户可控的环节里会出现真实数据
|
 |
29
urnoob 2023-04-04 16:51:47 +08:00
凡是在客户端密钥 理论上都存在被偷到风险。以前是 C 类写的客户端，现在是 js 而已。
|
 |
30
clf 2023-04-04 16:54:36 +08:00
后端才是定义业务逻辑、规则和限制的。前端是方便用户使用的。前端做的再花里胡哨，没后端限制照样白搭。后端限制做好了，管他用的啥客户端。
如果要保护中间传输和客户端，最好的方案是硬件层面的，比如直接拉专线，客户端设备做防拆和防调试，拆了就损坏数据的那种。 |
 |
31
ren2881971 2023-04-04 16:59:06 +08:00
你现在是属于信源加密，并且还没有保护好密钥。
如果想实现你理想的安全，需要采用基于 GMSSL SM2 保持信道加密。 然后采用非对称加密实现信源加密。 但是非对称加密是有性能损耗的，需要取舍。 |
|
32
zhywang 2023-04-04 17:01:48 +08:00
@ren2881971 话说为啥大家都在提 SM 算法，之前貌似大量使用的是 RSA/AES/3DES ，SM 已经作为规范被强制使用了吗？
|
|
33
ren2881971 2023-04-04 17:28:02 +08:00
@zhywang 对呀。现在都在推广 GM 算法了。SM2 、SM3 、SM9 这种。而且 op 主自己在主题里也写了使用 SM4 算法，说明他的应用环境是要求使用 GM 算法
|
 |
34
zddwj 2023-04-04 22:51:04 +08:00 via Android
根据你的描述，你需要的应该不是传输加密，而是业务逻辑保密的问题，这种情况一般是把业务逻辑放在后端处理，给前端传输处理后的数据，比如当用户隐藏积分大于多少的时候，就在 ui 上显示个什么按钮，你直接在后端计算好了，然后传到前端一个 bool 参数显示 ui 就行了
|
 |
35
layxy 2023-04-07 09:25:53 +08:00
加密传输只要确保传输过程的安全就可以,浏览器一侧基本没办法确保安全,尤其是浏览器这种能后拿到你加解密算法和秘钥,除非你开发一个浏览器插件来辅助加密
|
Select Language