这是一个创建于 987 天前的主题，其中的信息可能已经有所发展或是发生改变。
基本可以实现前端加密和后端解密，并且较难被破解的方法？
第 1 条附言 · 2022-03-10 10:24:16 +08:00
场景为 ajax 发送一个加密的字符串，给后端解密。该字符串的实际内容不想被用户抓包察觉
 |
1
leeyuzhe 2022-03-10 09:49:46 +08:00
rsa 不就行了，跟语言没关系啊
|
 |
2
cmdOptionKana 2022-03-10 09:53:37 +08:00
后端向前端发一个公钥，前端用公钥加密，密文传给后端，后端用私钥解密。
|
 |
3
ch2 2022-03-10 09:56:05 +08:00
->并且较难被破解的方法？
js 用 wasm 加密可以增大破解难度，但是本质上只要利益够大迟早会被破解 |
 |
4
watcher 2022-03-10 09:58:55 +08:00
用 wasm 加个壳吧
|
 |
5
LeeReamond 2022-03-10 10:00:18 +08:00
没方法，js 加密本身就很迷惑，加密算法无法保密->wasm 虽说可以编译，但解起来也就那回事，数据源也是暴露前端的无法加密，所以加密给谁看呢
|
 |
7
tagtag 2022-03-10 10:07:26 +08:00  1
建议描述一下你的需求，首先前端和后端的通信加密只要有 https 就可以了，除非是你前端产生的内容不想让用户看到所以加密传回后端，但是本质这个需求单纯通过 JavaScript 是不可能的，前端代码对于浏览器本身就是全透明的，你怎么产生的怎么加密的都没什么意义，顶多混淆了代码，看起来费点力气而已，wasm 楼上也说了，存在反编译问题，也只是增加了难度，所以问题应该出在需求上。
|
 |
8
cpstar 2022-03-10 10:09:25 +08:00
有个问题，公私钥是不是只针对非对称加密，LZ 需要的是不是一个对称加密，以及密钥分发方案。
|
 |
9
streamrx 2022-03-10 10:15:01 +08:00 via iPhone
怎么弄都会被破解， 只要利益超过破解付出的成本
|
 |
10
dzdh 2022-03-10 10:17:14 +08:00
场景呢？没场景？
登录密码加密吗？上 https 足够了，针对这个场景任何前端加密都是脱裤子放屁。 显示隐私内容？前端输入密码才能看？那应该是后端发来密文吧。 |
 |
11
maichael 2022-03-10 10:19:34 +08:00
前端加密是个永恒的话题，只能防懒鬼不能防有心人。
不过有时候还是要看你的需求，毕竟不同的加密需求有不同的解决办法。 |
 |
12
zhanggg 2022-03-10 10:37:46 +08:00
非对称随便弄一个就好了啊，私钥存服务器，公钥发给前端
公钥加密的内容即使被抓包也解不了啊，又没有私钥 场景交代的太模糊了，直接建议双向 https 吧，以保证双向信任和内容加密 就是每次打开你前端界面要贴证书才能访问 |
 |
13
xiangyuecn 2022-03-10 10:44:25 +08:00
重要原则：只要代码写的足够复杂，别人就会懒得看🐶，从而增加了破解难度😂。随便搞个位移，base64 过一下 就能糊弄住很大一部分人了
|
|
14
ch2 2022-03-10 10:47:24 +08:00
->该字符串的实际内容不想被用户抓包察觉
rsa 加密一下就行了，只有有私钥的才能解密 同一个字符串公钥加密之后每次密文都不一样，谁也不知道内容是什么 |
 |
15
500 2022-03-10 10:51:14 +08:00
这是个伪需求
|
|
16
tagtag 2022-03-10 10:54:42 +08:00
简单点就是把加密过程的代码进行大量的混淆操作，增加了读代码难度，复杂点就是把加密工程用 wasm 封起来，毕竟反编译的门槛一下子就上去了。
|
 |
17
sanggao 2022-03-10 10:56:22 +08:00
这样加密的意义何在？
|
 |
18
3dwelcome 2022-03-10 11:01:07 +08:00 3
前端想加密数据有几种方法。
第一个学 chrome 的 CDP ，给每一个 JSON 传输数据包，都弄一个服务器来维护的自增长 ID 。也就是每个请求就算被黑客抓取到也没关系，服务器的验证 ID 随时在变化，没办法重放。 第二个学 HTTP2.0 的二进制协议，用 gRPC 来封装 json 数据，对于二进制加密。前端最大的弱点，在于数据都是明文，黑客看一眼就懂。如果是私有二进制协议，他还要花时间分析，还未必能分析出来正确结果。 第三是学 websocket 的 zlib 扩展压缩，就是客户端和服务器各维护一个动态变化的压缩字典，这样黑客获取获取中间一段数据也没用，他没有对应的字典能正确解压，也是百搭。 |
 |
19
dongtingyue 2022-03-10 11:43:30 +08:00
@kisshere rsa 公钥只是加密。。。解密是私钥。
|
|
20
cmdOptionKana 2022-03-10 11:46:27 +08:00
@kisshere 用公钥加密的东西，用户没有私钥，如何破解？
|
 |
21
henyi2211 2022-03-10 12:44:52 +08:00
@cmdOptionKana 公钥加密，私钥解；私钥加密，公钥解
|
|
22
cmdOptionKana 2022-03-10 13:05:29 +08:00
@henyi2211 楼主说想在客户端加密，在后端解密；同时楼主又担心客户端用公钥加密的东西会被用户破解。我问，用户没有私钥如何破解。
|
 |
24
oldmanong 2022-03-10 14:16:47 +08:00 via iPhone
又遇到了用 12 位密码保护 2 位数余额的场景了😂
|
 |
25
wangritian 2022-03-10 14:28:30 +08:00
防中间人，https 足矣；防用户，尤其还是 web ，做不到
|
|
26
LeeReamond 2022-03-10 14:33:44 +08:00 via Android
@3dwelcome 对第一种情况，无论如何用户需要正常获取数据，黑客模拟此过程不是同样可以获取数据？
对于第三种情况，感觉与第一种相同，效果本质上是通过混淆前端逻辑增加查看源数据的成本。但似乎在调试工具下都无太大意义 |
|
27
LeeReamond 2022-03-10 14:35:58 +08:00 via Android
另外关于 Lz 的贴条需求，局限在 js 范围内个人感觉无法实现。前端破解有很多专业户，单纯加密逻辑即使搞得很复杂，专业人员理顺可能甚至不需要很长时间
|
|
28
3dwelcome 2022-03-10 14:56:53 +08:00 2
@LeeReamond 这问题在 V2 也讨论了很多次了。
上次讨论的结果是，前端加密一下，总比什么都不管，不加密要好。 也不能用静态密钥，不安全。需要算法来动态生成密钥，算法会频繁更新，让黑客没办法保存 JS ，也没办法反编译。都是服务器实时下发的动态脚本，必须联网才能获取。只要用户一直联网，就能限制访问频率和提高破解门槛。 现在网络安全要求很高，前端加密和后端数据库加密一样，也许很多人眼里看起来用处不大，但不能没有。安全就是一点一滴累加起来的。 |
|
29
tagtag 2022-03-10 15:06:37 +08:00
@3dwelcome 根据题主的描述场景就是有一个字符串是前端生成的要传回后端，不让用户在 DevTools->Network 中看到原始内容，所以就是要把这个内容的 generator 加密或者说隐藏的深一点，感觉您说的都是防中间人的，或者说是防止爬接口的。
|
|
30
LeeReamond 2022-03-10 15:06:41 +08:00 via Android
@3dwelcome 最近看到一些动态 js 的说法，很多前端加密公司都提到过，我没见过类似项目所以无法理解是怎样一种加密。一般来说，js 脚本核心数据交互功能还是向服务器请求或发送一段数据，而具体请求或发送的实现可以经过混淆让人无法理解传输的具体内容。不过按照你所说的话，黑客只需要保存某一时刻的所有传输信息，应该就可以解密当时刻下的代码具体行为，之后只需要在浏览器里对目标数据预先劫持就可以永远立于不败之地了，关于你说的让黑客没办法保存 js 我不是很理解
|
|
31
3dwelcome 2022-03-10 15:20:33 +08:00
@LeeReamond 动态 JS 可以在原来浏览器 JS 的基础上，再运行另外一套 QuickJS 虚拟机，加密解密就是运行在虚拟机里进行，算法可以在服务器实时生成。
对黑客来说，虚拟机就是字节码，看不懂。字节码可以埋地雷，必须按照一定的顺序执行，这能一定程度防止恶意修改，提高破解难度。 由于密钥算法是动态的，随时在变。那么下发的虚拟机字节码，也随时在变。保存的 JS 算法会过期，自然也就没有保存 JS 代码的意义了。 |
|
32
LeeReamond 2022-03-10 15:43:23 +08:00 via Android
@3dwelcome 大概理解了，意思是需要秘钥验证的场景，前端每次加密前都要向后端请求加密代码，而后端每次提供以不同逻辑加密的代码，使黑客即使解出单次请求的逻辑也无法复用。不过感觉上这个适合的应该是前端往后端发送数据的场景，对于接受数据保密的需求则无效。另一个问题在于，发送数据一般都需要通过基础设施获取，但 js 虚拟机我看到的一般是实现 es5 ，也就是说不管是 input 这类用户输入，或者从 navigator 这类基础设施获取数据，本身无法在虚拟机内部执行，如果获取后再输入的话，这个获取过程就很容易被预先劫持
|
|
33
3dwelcome 2022-03-10 15:50:10 +08:00
|
 |
34
orangie 2022-03-10 17:16:51 +08:00
如果目标用户具备网络抓包的能力，那么从用户的技能水平上说，可以说，前端的加密手段应该都对用户无效。
|
 |
35
sampeng 2022-03-10 17:56:10 +08:00
很早很早很早微博是不带 https 的。所以他的登陆就是 js 加密。然后我就研究了 1-2 天，大概搞明白了什么个玩法。细节不好说，原理上就是制造一堆参数，用一定算法随机选择。然后，RSA 加密不是要公钥么？任何公钥可以用私钥生成。只是需要一些算法参数。这个就是服务端加密了吐回来的。然后再加密秘文。。我还照着实现了一个
其实我觉得吧，前端加密都是防君子不防小人，只要你的内容足够他有用大量的时间研究，就没有解不开的，所以前提如果是你的数据重要到绝对都不能让对方知道，你为什么要用 WEB 网页的方式提供内容。参考银行，证券，就是绝对不能随便被抓包拿到数据的。。。又想简单，又想安全。对不住，没有银弹。。如果只是想给破解者增加麻烦，套娃就是了，越复杂越好。。只要解密成本大于你实际数据成本，就没人干这个事。我干过最复杂的事就是，把硬件编号，每一个用一个不同的算法加密，然后最后结果再套 3 层不同 key 的加密。。而且整个东西是二进制文件，内存里本身就是加密的，只有在使用的一瞬间，从十个不同的内存快拿 n 字节的数据拼起来，再解密。。。。谁爱破解谁破解去吧，毁灭吧。。随便 |
 |
36
GitContract 2022-03-10 18:23:47 +08:00
直接 https 不就完了吗
|
 |
37
0o0O0o0O0o 2022-03-10 18:35:20 +08:00 via iPhone
|
|
38
0o0O0o0O0o 2022-03-10 18:43:47 +08:00 via iPhone
@0o0O0o0O0o 我没有用过他的产品，所以不确定强度足够。但我相信只要是设计合理、强度足够的 vmp ，动态的 opcode ，正确的使用方式，破解起来还是没有楼上部分人说得那么轻松的。简单的办法：打开淘宝抓抓包，看看能不能很轻松就把每个加密数据分析出来。
|
 |
39
charlie21 2022-03-10 19:42:48 +08:00
这让我想起了 （ csrf 跨站请求伪造，一种网络攻击） csrf 的防御策略之一 csrf token 就是前端给后端发一个数据 后端凭此数据决定是否拒绝访问
https://tech.meituan.com/2018/10/11/fe-security-csrf.html#前端安全系列（二）：如何防止 CSRF 攻击 就你这个问题而言，具体解决方案 很可能并不在于对明文的加密和解密手段，而在于发送的内容和约定的解密方式。最简单的保密例子是 你可以在发起端发十句谜语，在接收器端决定十句里的第五句谜语是真正起作用的谜语，那么即使在发起端（客户端）抓包拦截到 10 句谜语了 拦截者面对受混淆的信息 并不知道真正起作用的是哪一句，这是服务器端才知道的，那么是不是只要保证解密办法是仅有解密端知道的就可以了呢 |
 |
40
aleen42 2022-03-10 20:27:05 +08:00 via Android
IDEA Cipher: https://github.com/aleen42/IDEA
|
 |
41
lululau 2022-03-10 21:24:22 +08:00 via iPhone
web 加密难道不是应该用 https 吗。。。
|
 |
42
poplar89 2022-03-11 09:47:16 +08:00
好多人在等着 OP 的需求场景，OP 哪里去了 😳
|
|
45
sampeng 2022-03-11 14:52:56 +08:00
其实 99%的需求下，前端加密。
你以为的：抓包，拿到数据，把 js 代码整理一下稍微阅读，然后看加密逻辑，然后解密。 实际的：抓包，妈了个蛋，这货居然加密了。。搞不了搞不了。。逃了逃了。。。 |
 |
46
h2ero 2022-03-11 16:36:43 +08:00
这种方式没有什么用，只能防下小白用户
|
|
47
aleen42 2022-03-11 21:21:43 +08:00 via Android
如果說需要加密一些敏感數據的傳輸，RSA 是足夠並且在 js 層面是無法破解的。但 RSA 畢竟是非對稱，有其局限性而無法對較大的 request body 進行加密，這時候如果只是考慮對付小白，可考慮 IDEA Cipher 等對稱加密。如果真考慮安全級別，就直接上 SSL 或者通過 worker 做本地端加密吧。
|
Select Language