这是一个创建于 2631 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前在开发一款 App,过程中发现客户端和服务端传输数据可能会发生数据泄漏或者安全隐患，服务端采用的是 java，以主流的框架开发的 spring 为主，数据传输以 http 协议，格式为 json，对于敏感数据做了部分的安全处理，在客户端进行了数据加密再进行传输，但是响应结果以 json 暴露了出来，感觉有点不放心，不知大佬们有啥手段可以处理，我通过抓包拦截其他 app 请求，发现其响应结果都是被处理了，看到都是乱码字符,V 友们友 app 开发经验的希望可以多交流知道。小弟恭候 V 友们！！！
 |
1
zgbgx1 2017-09-19 14:21:47 +08:00
没做过 app 开发，但是返回的数据混淆或者加密的意义并不大
安全，首先上 https 吧 如果 你不像被直接抓包，就直接加密的字符串，再到 app 进行解密，这和前端解密应该是一个道理 |
 |
2
LeeSeoung 2017-09-19 14:22:30 +08:00  1
乱码是上了 https 吧，https 也是可以通过在手机安装 fake 证书抓包的。。只要在你接口那边做到参数严格检查，校验数据完整，不被非法修改就够了吧。。返回明文密文关系不大，密文在你 app 内部还是要被解密，照样能被人拦截。。特别重要的。。上 tcp，自己定义套通信协议。。没人能看懂那种。。
|
 |
3
banksiae 2017-09-19 14:22:47 +08:00
pb 传输，减少数据包大小。数据加密，一般 aes，或者找个开源的算法改一下；
|
 |
4
hugedata 2017-09-19 14:43:51 +08:00
有 fiddler 在 https 也一样玩儿玩。不过有总比没有好，还是 https 先上了吧。123 楼建议均可以考虑。如果有富余的时间和精力的话，把用户行为加上吧，判断是否是机器人。加上黑名单 IP，比如垃圾邮件的黑名单，IDC 机房的黑名单之类的。哪儿有绝对安全的系统哦。唉。
|
 |
5
miaomiao0323 2017-09-19 14:44:27 +08:00
传过去加密了，返回回来当然也可以加密啊，服务端加密，客户端解密，安卓的话算法和 key 不要用 java 写，写在 so 里
|
 |
6
zjw7sky 2017-09-19 14:46:41 +08:00 via iPhone
数据传输加密，解析解密，通用参数不加密
|
 |
7
pangliang 2017-09-19 14:47:54 +08:00
返回结果加密的意义真的不大, 就一个心里安慰而已
|
 |
8
zhouyou457 2017-09-19 14:57:44 +08:00
https 传输，敏感数据 base64 加密，再不行把数据打成 zip 包再用 base64 加密然后传输过去
|
 |
9
whatgui 2017-09-19 15:05:19 +08:00
https 解决你的一切问题。不要自己再去造轮子了。
|
 |
10
sunchen 2017-09-19 15:12:13 +08:00
@zhouyou457 base64 是编码。。。
|
|
11
sunchen 2017-09-19 15:16:48 +08:00 2
1. 上 https, 加验证证书逻辑，防止中间人,
2. 数据用 aes 之类的进行对称加密，可以和加密逻辑整体写到 so 里 3. app 混淆加固做好，防止直接逆向和被 xposed 劫持 |
 |
15
mornlight 2017-09-19 15:22:05 +08:00 1
如果是不想通信过程被窃听或篡改，部署 HTTPS 就行了。如果连被用户自己抓包都不想，就在客户端 Pin 证书。
|
|
16
LeeSeoung 2017-09-19 15:24:05 +08:00
@sunchen 不解析协议到数据结构，纯粹解析数据流执行对应条件分支。。我相信够恶心一部分逆向的了。。再保险点，把通讯过程放到 so，so 也做加密处理。。- -我觉得这么一套下来估计够呛了。
|
|
17
hugedata 2017-09-19 15:29:08 +08:00
@sunchen 好吧，客户端，但是用 http 测试工具之类的来模仿客户端的话，就不存在“客户端对证书验证严格的话”这种情况了，比如写爬虫时分析对方的返回 json 数据的服务时，不都是这么干么。
|
 |
20
sumuu 2017-09-19 15:41:37 +08:00
我一般会从两个点去看待这样的问题.
1. 数据是否必须强加密? 很显然,不是什么数据都需要去加密,因为加密还是需要一定的成本. 2. 如何加密 AES 就好. 接口数据安全的处理? 1. 所有请求和响应都会把相关字段加密,生成一个 sign 的字段,然后 接受数据方需要做数据校正. 2. 敏感信息,都是服务端加密,客户端无法解密. 最后 HTTPS 是必须的,不是盲目崇拜 HTTPS,这个是基本,就像换衣服你得在家里等,不会在外面. |
 |
21
kohos 2017-09-19 15:46:45 +08:00
与其去想如何加密，不如去想如何在服务器端检查伪造数据和发包机器人。反正客户端都到用户手里，https 装个 fiddler 证书可以拦截，so 用 IDA 反编译也可以破解。市面也有不少安卓保护服务，但多逛逛看雪论坛也还是有不少被攻破的
|
|
22
kohos 2017-09-19 15:50:09 +08:00
补充一下 https 还是有必要上的，fiddler 只能拦截安装了破解证书的设备，其他人正常的设备一般是拦截不了的，就算在路由器网关上拦截到的包也是加密的
|
 |
23
janus77 2017-09-19 15:55:57 +08:00
https
参数加个自加密的签名 服务器和本地时间校验 限制重复请求次数 |
 |
24
l12ab 2017-09-19 16:00:18 +08:00
彻底的安全应该是没有，只能加大被破解的难度
http，加上 Pin 证书校验，URl 混淆，参数混淆，带 token 参数 |
 |
25
vus520 2017-09-19 16:27:59 +08:00
看了一下，都说 HTTPS 能防解密？？？乱说什么大实话。所有通信，只要是最终会解密的，都有可能泄露。HTTPS 只能解决传输过程中不被篡改。
最安全的是，是请求加签名，通信做加密，其它的，就看遇到什么样的对手吧。 |
 |
26
whileFalse 2017-09-19 16:38:12 +08:00
@vus520 #25 https + 客户端校验证书，客户端不被破解的情况下防解密。
|
 |
27
z1113456051 2017-09-19 17:30:56 +08:00
不重要的参数加一个校验防止修改，重要的参数加密在传。
|
 |
28
Kaho 2017-09-19 18:07:57 +08:00
我这里是 aes + rsa.
|
 |
29
geelaw 2017-09-19 20:40:25 +08:00
上了 HTTPS 就没有别的需要做的了。
你的程序能做的，用户都可以做。如果系统上没有一种隔离你的程序和其他程序的功能，那么你的程序能做的，其他程序也能。 |
 |
30
u5f20u98de 2017-09-19 20:56:58 +08:00
通讯安全:
tls+客户端强制证书校验，防止随便导入个信任证书就被抓包了。必要时可以进行双向 tls 认证。 协议安全: 1.对每个请求和回复进行摘要算法签名，附到包的结尾或者 header 里。实现过程需用 C 实现加大逆向分析难度，且算法也要复杂防止被暴力枚举出来，必要时可以对.so 加壳或者混淆。同时在 jni 调用时 C 的代码也要倒过来验证调用的 APP 是不是真正的 APP 防止被人直接拿来调用。 2.对请求和回复参数进行加密（可选），处理方法可以参考上一条。 |
 |
35
kim2x OP @miaomiao0323 目前只在客户端传到服务端加密了 待修正
|
|
37
kim2x OP @zhouyou457 base64 编码没啥用 ，
|
 |
39
wuhau 2017-09-19 22:21:45 +08:00
1. https.
2. 签名认证。一般 md5(key1+key2+key3) // 可以按照实际情况更改，可以防止一般的修改数值重放攻击。 3. app 加固，如果逆向出你的客户端协议，以上根本没卵用。 4. 返回数值用 rsa/aes 这种加密，可以增加对流量包抓包分析的难度。 5. 做好 api 权限控制，防止越权等情况出现。 6. 服务器安全加固（做了这么多，服务器账号密码都是 root，这都说不过去吧。） ===== 如果有什么不对，和需要完善的地方，还请各位指正／补充 |
 |
40
imjeen 2017-09-19 23:21:55 +08:00 via Android
楼上很多说 HTTPS 协议，其实楼主想要的是 JWT 加密 JSON 格式数据
|
|
41
kim2x OP @imjeenHttps 是肯定的 、JWT 感觉不怎么有效果 这东西好像在服务队还是无状态的 不怎么安全
|
 |
42
cevincheung 2017-09-20 00:19:40 +08:00
@LeeSeoung #2 SSL Pining + 内置二次封装的 SSL 处理包可破
|
|
43
LeeSeoung 2017-09-20 09:15:59 +08:00 1
@cevincheung 网上已经有针对 SSL Pining 的破解方法了，还是#29 说的对，只要你的程序能做的，别的程序也能做。如果你能做到破解成本大于破解后的收益就够了。。
|
 |
44
nicevar 2017-09-20 09:50:43 +08:00
看你想挡住多少人了，绝对的安全是没有的，https 还是很有必要的，另外自己把加密封装在 so 里，然后对 so 再进行处理，这样能挡住百分之九十的人了
|
 |
45
raptor 2017-09-20 11:31:11 +08:00
HTTPS 可解决 80%的安全问题和至少 20%的其它妖蛾子问题（比如被运营商或路由器劫持之类）
|
|
46
zhouyou457 2017-09-20 11:36:34 +08:00
|
 |
47
q9S 2017-09-20 13:48:41 +08:00
上 api 网关
|
 |
48
phx13ye 2017-09-21 08:37:17 +08:00
https,用 httpclient 一般配置成绕过证书校验，自己实现一个 X509TrustManager 和 HostnameVerifier，这样还安全吗??
|
Select Language