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

[billbob]

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

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

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

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

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

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

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

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

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

我知道了来龙去脉，这是个什么法？

360 去年把甲方小程序给市公安局举报，说小程序明文传输有重大泄露国家机密，工作人员。

市局找了我们甲方，甲方找 360 不知道咋弄的，成了第三方检测机构，给出了一个详细报告。上线时候肯定做过验收的。

我们拿到报告很多就是一个截图，盲猜的，今天大领导问才去对接这个事。

就说我们这个联系人接口明文传输，因为是在腾讯第三方运行，没有加密，查看详细人员信息，没有二次确认，后端日志记录不详细。

我们有日志，存数据库的 json ，界面没有显示清楚。到此让我们赶紧修复。

领导说甲方还跟 360 签了合同，以后上新功能，检测都是他们做了。

我知道了来龙去脉，这是个什么法？

360 去年把甲方小程序给市公安局举报，说小程序明文传输有重大泄露国家机密，工作人员。

市局找了我们甲方，甲方找 360 不知道咋弄的，成了第三方检测机构，给出了一个详细报告。上线时候肯定做过验收的。

我们拿到报告很多就是一个截图，盲猜的，今天大领导问才去对接这个事。

就说我们这个联系人接口明文传输，因为是在腾讯第三方运行，没有加密，查看详细人员信息，没有二次确认，后端日志记录不详细。

我们有日志，存数据库的 json ，界面没有显示清楚。到此让我们赶紧修复。

领导说甲方还跟 360 签了合同，以后上新功能，检测都是他们做了。

我知道了来龙去脉，这是个什么法？

360 去年把甲方小程序给市公安局举报，说小程序明文传输有重大泄露国家机密，工作人员。

市局找了我们甲方，甲方找 360 不知道咋弄的，成了第三方检测机构，给出了一个详细报告。上线时候肯定做过验收的。

我们拿到报告很多就是一个截图，盲猜的，今天大领导问才去对接这个事。

就说我们这个联系人接口明文传输，因为是在腾讯第三方运行，没有加密，查看详细人员信息，没有二次确认，后端日志记录不详细。

我们有日志，存数据库的 json ，界面没有显示清楚。到此让我们赶紧修复。

领导说甲方还跟 360 签了合同，以后上新功能，检测都是他们做了。

[realpg]

没必要那么麻烦 直接用一个固定密钥 AES 就行

[sagaxu]

明文返回数据不是问题，数据越权是极其严重的问。框架层面统一做一下 aes ，这个好解决，权限就稍稍麻烦一点了。

[zhangrandl]

你就做个 base64 就行了，大部分扫描都是只扫明文

[zgsi]

不想加密就 base64,想加密就 aes

[billbob]

@sagaxu 不行啊,小程序是腾讯的,怕数据泄露

[billbob]

@zgsi 我问问可以不.
证书也是在小程序保存这个,感觉还是不安全

[coderzhangsan]

同#2 明文是小事 数据越权是大事 问题分清楚主次 然后依次解决

[Dewchame]

我们公司之前做的小程序基本上都是 aes 加密 然后再上一道 base64

[ciyouwu]

有敏感信息的，是一定要加密的，现在不都使用国密么，只要数据加密了，大部分的越权问题也能解决。但是从根本上解决越权还是要做身份验证机制，即用户访问的数据和实际身份做严格划分。。

[zjsxwc]

把权限机制加上呗

[mmdsun]

这个没必要做。如果是应付检查怎么简单怎么来。数据越权要处理。

用 https 即可防数据泄露。要说什么 F12 查看网络请求是明文的 这是防不懂的客户挑刺，根本不是防黑客好吧。

[HDF]

“甲方找的第三方扫漏洞,说我们明文返回数据,数据越权”，这个是明文传输还是越权漏洞？，如果是越权的话前端加密是不解决问题的，要鉴权。

[cheng6563]

@ciyouwu 这俩没点毛关系，前端加密犹如皇帝新衣。数据越权跟加密也没几分关系。

[chairuosen]

明文返回数据有两种情况，1 是明文返回了用户手机号等隐私信息，这个是要做脱敏。2 是说普通不敏感数据传输过程明文，这上了 https 就无所谓，爱抓包抓呗，反正只能抓自己的。

[tcper]

很多不太讲究的项目，存在水平越权，扫描工具轻松就给你扫出来了。

[wangtian2020]

明文返回数据还要被说有点幽默了，这个甲方估计也不怎么样，随便糊弄糊弄把他第三方过了得了。
base64 一下返回值，再把一个接口的路径映射一下成两个路径，看能不能通过

[dode]

小程序有没有强制 HTTPS 访问？

[billbob]

@chairuosen 人家就是 f12 ,看到客户列表是明文的,有联系方式,姓名照片.
越权 是它用不同 ID 能把数据拉出来,说要显示客户详细数据要二次验证,谁在看不能显示客户联系方式,地址.

[chairuosen]

@billbob #18 这是我说的脱敏问题，而不是加密问题，隐私数据就不该返回，而不是加密的返回

[xuanbg]

加个新接口不是很简单的事？搞原先接口不是更麻烦？

[chairuosen]

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

[AS4694lAS4808]

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

[EliStone]

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

[Vegetable]

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

[billbob]

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

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

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

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

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

[billbob]

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

[billbob]

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

[cdlnls]

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

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

[tianzi123]

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

[strongcoder]

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

[wolfie]

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

[billbob]

@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 ， 运维人员也无法直接查看字段，也不敢篡改。