使用了 HTTPS 的网络请求, 其中 JSON 数据有必要做额外的加密吗

2020-06-13 18:54:34 +08:00
 wjploop

假设客户端 app 的代码是安全的,没有被反编译查看。

另外,我使用 finder/charles 代理工具,并在手机添加证书,可以查看到 https 请求内容(仅在 android 低版本有效)。

想知道大家对于安全这块怎么处理呢?

4282 次点击
所在节点    程序员
24 条回复
xnode
2020-06-13 18:59:21 +08:00
https 在公网上 可以大致保证数据不被篡改,但是数据仍然可能被窃听,但是除非重要数据 否则不需要加密
qq292382270
2020-06-13 19:16:28 +08:00
能加密最好加密. 数据安全靠的是加密,https 并没有带来多大安全感.
hakono
2020-06-13 19:19:48 +08:00
https 防的是传输过程中的攻击
json 加密防的是来自本地用户的攻击(做外挂,作弊

根据你自己的需求来选就行了
dearmymy
2020-06-13 20:15:15 +08:00
除非你 https 是双向校验,不然一个中间人攻击就可以了。
如果假设 app 是安全的话,双向校验的确就够了。
但事实上客户端扔出去就被各种搞。安全这块,看你自家软件业务,体量了。
ZRS
2020-06-13 20:18:00 +08:00
@xnode TLS 同时保证数据的完整性和保密性,只要信任链是正常的就没问题。攻击者只能获取你访问的 IP 和域名以及传输的密文。
yuzo555
2020-06-13 20:18:08 +08:00
客户端能拿到的数据,攻击者就能拿到。

就看你的数据值不值得攻击者花费时间精力金钱去拿了。
janus77
2020-06-13 20:23:06 +08:00
没有绝对的安全,要不要上只是根据自己的实际情况选择。
说白了,我回答不用,你就决定不用了?那出问题要不要我背锅啊
learningman
2020-06-13 22:21:44 +08:00
SSL Pinning 试试?
CRVV
2020-06-13 22:54:03 +08:00
> 客户端 app 的代码是安全的,没有被反编译查看

如果这个假设成立,只要在客户端代码里判断一下服务器的证书是不是你的证书,问题就解决了。

密码学的一个常识是不要自己写代码做加密,不要做额外的加密,没有用。
QUIOA
2020-06-13 23:37:55 +08:00
dullwit
2020-06-13 23:40:27 +08:00
重要业务数据还是加密吧,防止 MitM 中间人,不过这个客户端貌似可以检测出来
testcaoy7
2020-06-14 08:17:57 +08:00
我觉得没必要。只要你用的正规证书,而且 TLS 配置的没问题,那么数据完整性和保密性都是已经在 TLS 层提供了的
testcaoy7
2020-06-14 08:20:03 +08:00
如果你做额外的加密,那么解密密钥的安全分发又会成为问题,最后等于要自己实现一套完整的密码学协议,然而造密码学轮子是最不推荐的,稍有不慎就会有漏洞
varint
2020-06-14 10:54:32 +08:00
@CRVV
@testcaoy7 自己造轮子只能被爆菊+1,本人逆向菜鸡,根据教程爆了一个 app 的菊,这个 app 还是加固了的,json 字段用 3des 加密的,md5_sign 加了盐的,通通都被抓了现形。
testcaoy7
2020-06-14 10:58:23 +08:00
@varint 以前看到哪个号称有国家密码局认证的加密 U 盘,在参数里面赫然写着加密方式是 DES,吓死我
shuangya
2020-06-14 11:12:05 +08:00
一般不需要,除非有很重要的保密信息。不过有这种信息的一般也不会是谁都能看到的,本身的传播源就是可控的。
至于抓包,那是没办法的事,用户本地抓包、反编译,你也不好管控。
防范中间人攻击,那只要用户本身系统没有问题,你们服务器也没有问题,那就不存在问题。
如果真的有很特别的需求,那你自己再加一层简单的加密也行,但不要报太大希望,这个只能是增加破解成本罢了。
总的来说,如果没有特别需要,没必要。
wanguorui123
2020-06-14 11:24:33 +08:00
只要 HTTPS 的证书合法,对无效证书进行过滤,应该没什么问题。其次不管如何加密没有绝对的安全,只能提高破解成本。
Warder
2020-06-14 12:54:18 +08:00
最近我也在想有没有那种基于 json schema 压缩的方法,之前看 google 的 http 请求结果上的字段都是混淆过的 。
howellz
2020-06-14 15:38:59 +08:00
客户端在人家手上,只要想揉拧,都是软柿子。
一句话,这种在消息上加密的普通做法(不包括其他对程序进行比较复杂的加固):不重要的业务没啥必要;重要的业务没啥鸟用。因此不建议用这种方案。
kimi0
2020-06-14 21:30:52 +08:00
看了前几楼的回答,觉得有必要回复一下这个帖子来澄清一些基础概念。
然后再往后看几楼,发现已经有朋友解释过了,就不再赘述了,2333

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/681294

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX