请教 客户端/前端的安全措施有什么意义？

[luckykelan]

大家好，问题的背景是这样的：我们的项目已经上线了，但是竞争对手公司也在搞这方面，所以想尽可能的保护接口数据，最近做了以下尝试：

1. mtls ，证书双向认证。但是客户端证书一直没有找到安全的存储方式，在客户端以硬编码存储，反编译以后就是明文了，以文件存储，将 APK 解压也会获取。
2. 接口加密，我使用国密算法模拟了 https 的部分过程，在客户端/前端生成一组非对称加密密钥，用私钥进行签名，将签名后公钥传到后端，后端验签后会将对称加密的密钥使用传过来的公钥进行加密，返回到客户端/前端，后续的接口使用该密钥进行对称加解密。 虽然费了很大劲做了安全措施，但各位应该看出来了，其实破解起来并没有太大的难度 所以我的疑惑是客户端/前端的数据安全有办法保证吗？似乎不管用什么方式，破解起来都是体力工作...

[foam]

就像捏柿子

[Helsing]

只要是客户端就没法保证绝对安全，因为拿到你的 apk 只要愿意花时间就总能破解

简单有效的处理，换 Flutter 来写客户端，目前逆向比较难

[LeeReamond]

可能是个永恒难题，蹲一个答案。一个提高成本的方式是 wasm 编码部分运算过程吧，要解 wasm 还是比解 js 复杂不少的。还有就是算法是不是可以实现动态更新

[laofan666]

没做过这类需求，但是有个想法，
服务端数据用私钥加密之后再加一些自定义的字符，客户端公钥解密之前先把字符去掉，
这样即便公钥被破解也无法解密接口数据，
客户端删字符的算法代码加点混淆，经过编译之后没那么容易破解

[0o0O0o0O0o]

客户端确实没有绝对安全，不过你描述中的防护约等于无，是要配合很多防护一起做的，常见的：反调反 hook 、混淆、代码虚拟、检测、反反编译、白盒…去买产品吧

[keakon]

不是政治要求的话，那些国际通用的加密算法才是安全的。
国密基本上是把这些算法拿来，将其中随机的参数设置成一个预设的常量，不但降低了安全性，还可能藏有后门。

关于破解可以说没有任何安全的防御手段，前公司破解了大量竞争对手（网络安全行业）的产品来研究。

关键是算法和数据才是有价值的，保护接口有啥意义？你看 OpenAI 不也开放了 API ，那么多开源模型都抄它的 API ，但是最终比的不是模型的质量么？

[erwsd32ew]

你孱弱谁都可以欺负你所以你觉得大门不重要没安装，一个 200 斤的胖子可以过来揍你一顿，一个特种兵也可以过来一拳撩倒你，但是你不能某天早上睁开眼发现一个三岁小孩的鸡鸡对着你的脸撒尿。

[erwsd32ew]

谈到有效的方案，有钱就买 360 企业版，代码混淆，接口数据加密，证书校验，没钱就 flutter ，但是这都是中小厂方案，其实你可以发现头部大厂的 apk 其实大部分是裸奔的，安全并不在客户端。

[dododada]

接口没啥用，客户端要加固，梆梆，360 ，活着其他的，你们有能力就自己写。
但是加固的话，每个版本可能都要重新适配

[InkStone]

客户端安全的原则是：破解利益<破解成本 === 安全。

国密 tls 有现成的库，别想不开自己写……这玩意儿正确实现基本破解不了的。

[InkStone]

@erwsd32ew 头部大厂客户端大部分是局部加固的，主流做法是虚机方案。如果完全不做加固，黑产真的能把他们底裤都脱掉。

[shakeyo]

@keakon ‘国密基本上是把这些算法拿来，将其中随机的参数设置成一个预设的常量，不但降低了安全性，还可能藏有后门‘ 能不能对你自己不懂的方向有点敬畏，搞技术的至少得做些研究再发言吧

[FengMubai]

@laofan666 逆向你的自定义规则可比破解公钥简单多了

[FengMubai]

客户端要保证数据安全, 只能让密钥只存在内存里

[FengMubai]

@FengMubai #14 公钥除外

[jones2000]

能展示出来的数据，直接截图 AI 识别下，基本就能抓。

[meshell]

写几个 SO 吧。难度加大 点。

[flyPig9527]

用户量不大一点必要都没有

[FengMubai]

1. 双向证书没用

2. 你把服务端公钥硬编码到客户端, 客户端生成对称密钥后, 携带 nonce, 一起用公钥加密发送到服务端, 服务端拿收到的对称密钥加密 nonce 返回

[sampeng]

1.双向认证安全那是两边都是服务端才有用
2.前端安全措施从来都是防君子不防小人。增加破解成本，99%的破解的人你就是加个随机数就够他喝一壶的。这事没有什么绝对。n 年前微博的加密就在前端做的。逻辑我都翻出来了并套用到我自己公司的登录项目里面。但我依然破解不了微博的密码加密。因为他有 30 多个参数互相作用。。我人都给看傻了。再一个，就算我知道了怎么解密，第一道关就是怎么获取别的用户的流量而不是自己端的流量。。自己端的流量 https 都随便看，是无所谓的事。这道关可以拦截 99.99%的脚本战士

[BadFox]

增加攻击成本。单纯的双向证书只能说把门关了，人家一推就开。但就算只做到这一步你也可以拦住很多直接抓包改包的初级脚本小子了。配合反调反 hook ，混淆，反反编译等，就算是这么不仅关了还挂了个不错的锁，虽然别人也能破解但是成本骤然上升了很多。

另外做安全不能以定性的思维来做，不能因为一个手段有可能被破解就觉得可以去掉。安全永远应该以定量的思维来分析，没有绝对的安全，但是我们能思考在付出一些可接受的代价的情况下可以安全到什么程度。

[hwf]

可以说没有任何意义, 特别是想隐藏接口数据的

[tflins]

增加攻击成本，就像只做一个简单的客户端加密或验证，也能杜绝大部分低成本的简单攻击

[monkeyk]

所谓更安全就是增加复杂度；增加被拿捏的时间长度。
---- 做多年安全的总结

[snowgao]

就是典型的防君子不防小人