关于一个前端数据和后端数据加密的问题,项目组长都急了!

[AlexBob]

最近给甲方做的小程序项目因为赶时间,没有权限隔离,大部分 API 和管理端共用.

甲方找的第三方扫漏洞,说我们明文返回数据,数据越权.

为了解决问题,我们经理想到 用 (RSA+AES+HMAC 校验)给数据加密.

这个有必要做吗?或者有更简单的方案吗?

[chairuosen]

你应该做的是老老实实给这个原本给 B 端的接口封装一下，加上权限校验，脱敏逻辑，给 C 端。而不是投机取巧应付检查加个 base64 只要扫不出来就糊弄过去

[AS4694lAS4808]

听上去像一个接口既可以用前端登陆后的默认 ID 返回普通用户自己的信息，又能作为管理作用返回任意传入 ID 的信息？如果没理解错，这种是要被甲方打死的漏洞吧。。

[EliStone]

越权加密没用，没做权限管理，至少我上次是对请求参数和返回结果加密（国密要求），结果就是 oom ，这玩意加解密太吃 CPU 了，访问量一上来直接把服务器打挂了

[Vegetable]

完全两码事，明文只会看一些密码之类的敏感数据，随便脱敏 base64 一下就差不多了，越权才是关键。

[AlexBob]

这个就是给他们人显示,就是一个代表联系人列表,业务就是这.

"越权"的意思就是这个列表点开联系人详细信息,要二次验证.

不过这些信息要加密,不能明文传输,即使是 HTTPS.

不好意思怪我没说清,我也了解清楚了.

我们今天给所有接口加了一个 RSA+AES+HMAC

[AlexBob]

他们都没高清业务逻辑,我怀疑这个检测业务都不懂,还是 360 啥的

[AlexBob]

扯了半天,我们现在也把加密证书在 APP 里面的,我感觉没啥意义,不过估计他们找不到,藏的很深.

[cctv6]

如果说真的 没有权限隔离/数据越权，那只能说项目做得确实粗糙，权限隔离已经是基础问题了，要我说就应该回炉重造一下。

数据加密虽然能让渗透安全测试的难度提高一个档次，但是权限问题依然存在。

[19cm]

360 倒是真孙子啊, 为了接业务直接举报

[strongcoder]

很正常, 之前我们公司也有类似情况反馈,
后来我们就和服务端商量一个 AES 加密串 一起加解密就行了,
只要不能在接口提交和返回的数据里面有明显的手机号就 ok 了

[wolfie]

碰到过，整个请求体 AES 后用表单提交，后端根据规则 拦截器适配就行。

[AlexBob]

@strongcoder 现在行业是真的暗，我闷甲方还是国家的，这不明显在碰瓷么，感觉在 py 交易

[mark2025]

难道 AES 在前端进行解密？ 那密钥不也得在前端保存一份么

[shangfabao]

最简单的,双端写死加密密钥,数据密钥传输，麻烦点就前端去后端获取

[FaustY]

所以前后端加密是不是无用功呢？

分析下：
1 、对称加密，密钥暴露在前端，获取到之后可以直接解密，故不管对称加密来加密请求/响应体，还是非对称的密钥，都没有意义！
2 、非对称加密，公钥加密，私钥解密，请求根据发送和解析分为两对密钥：1 和 2 。
① 发送的请求体：前端公钥 1 加密，后端私钥 1 解密，只有公钥 1 暴露在前端，他人对请求体无法解密，安全！
② 接受的响应体：后端公钥 2 加密，前端私钥 2 解密，用来解密的私钥暴露在了前端，他人对响应体可以解密，不安全！

所以结论就是：非对称加密完全没必要，即使是用来加密对称加密的密钥对；对称加密只对请求的加密有效，对响应的加密没有任何意义。

PS: 领导让加就加，没办法。

各位大佬看我分析的对吗？

[jeesk]

谁说加密没用？

1. 防止服务端抓取内容

简单的说，比如 signal ，就是端到端加密，这个时候双方交换公钥。

a 用户使用 b 用户的公钥加密， 持有私钥 b 用户 的用户就能解密，服务端是无法解密的。

2. 登录场景 防止传输过程解密

浏览器先从服务器获取到登录的公钥，然后登录使用公钥加密，这个时候只有持有私钥的服务器才能解密。传输过程即使破抓包破解也没用，无法解密。

3. 数据库加密防止篡改

比如一些重要的数据信息，需要对字段加密，然后做 sha256 ， 运维人员也无法直接查看字段，也不敢篡改。