手机客户端一般怎么保护 api

2019-11-12 22:04:28 +08:00
 witcat

现在正在做一个小软件,主要内容是菜谱一类的。
以前做的都是个人小作品,接口都不加密的。但因为这次的内容价值比较高所以想把安全做好一点。

现在用了基本的 hmac 加密和 jwt
其实我理解这个加密根本上依赖的就是 hmac 加密用的 secret (因为只要反编译了算法就是透明的)

在小程序端做这个很简单,因为小程序有登录 api,可以在后端核实小程序的信息,然后返回 secret 和 token 给前端来加密请求。secret 是根据 token 在服务端生成的。

我打算用 react native 继续做 iOS 和 Android 客户端,这样就不能用小程序那种方法了
secret 肯定还是不能在前端存储或生成,rn 的客户端应该很容易反编译

如果从服务器获取,也想不出来可以用什么凭证,
一般大公司都怎么做呢?特殊的储存方法?还是?...想不出来了

4665 次点击
所在节点    程序员
19 条回复
cxtrinityy
2019-11-12 22:36:19 +08:00
hmac 不是做完整性校验的?跟加密有什么关系
和服务端交互上 https,客户端如果不联网,不管对称还是非对称加密,解密密钥肯定存在本地,你的内容真的值得别人反编译破解那总是有缺口在那
如果客户端连网解密,密钥存服务端,AES 啥的就行
bazingaterry
2019-11-12 22:47:48 +08:00
微信的 mmtls
janus77
2019-11-12 22:48:48 +08:00
安全这种东西是看成本的,就算你是商业产品,只要日活太少,不防一样没事。
hkitdog
2019-11-12 22:51:20 +08:00
参考抖音做法,自行研发一套基于 TCP 的传输协议,或者直接抄过去,抓包什么都看不到,Android 平台上,加密解密算法可以刻在内核上,最好自研,aes 这种烂大街就不要用了,经 IAT 动态调用,过程不经 Java 层,全用 C++写,在加个压缩刻基本很难逆
hkitdog
2019-11-12 22:52:49 +08:00
不想自己写的,用 360 加固吧,最低成本
hadesy
2019-11-12 22:54:50 +08:00
各大加固厂商的密钥白盒了解下
witcat
2019-11-12 22:59:20 +08:00
@hkitdog #5 这个我看行 😂
Foxkeh
2019-11-12 23:01:02 +08:00
ios 上我就留了三个
过日子,健康养生,最近加了 懒饭
你也是这一类的吗?期待你的作品。
witcat
2019-11-12 23:02:34 +08:00
@Foxkeh #8 鸡尾酒酒谱 类似 cocktail flow 但是是全中文的
witcat
2019-11-12 23:12:12 +08:00
@cxtrinityy #1 如果是需要联网的,AES 加密用的 key 也是存本地的吗?那这个 key 如果被反编译拿到是不是也可以随意伪造请求了。
其实我就是想问一下有没有和小程序里那种一样低成本的方案,目前看是无解了,可能试试第三方加密。
elarity
2019-11-12 23:17:56 +08:00
murmur
2019-11-12 23:31:38 +08:00
风控+律师团队+native 混淆级别的签名以及加密算法
witcat
2019-11-12 23:50:09 +08:00
@elarity #11 这个看起来不错,没有仔细看,作用是不是反爬作用更大?
我是想验证客户端真实性,找一种可以动态获取 secret 保存在内存里的方法(不在客户端存储 key ),
我现在主要想不通的就是怎么限制用户获取 secret,因为如果不鉴权,获取 secret 的接口调用是无限制的,这样任何安全都形同虚设了
但是对于菜谱来说,不能强行要求用户登录才能看全部内容
好像还是存在本地加固 app 靠谱一点
eason1874
2019-11-13 07:42:44 +08:00
加固讲成本,破解也讲成本,把破解成本加大到一定程度就能让人失去破解的意愿了。

数据价值特别高那就要求登录,通过 access_token 实现访问控制。数据价值一般高,那只要防抓包和防反编译就行了。防反编译可以用大厂的 APP 加固。防抓包纯粹 HTTPS 不够,可以每一个版本内置一个对称加密算法在 HTTPS 的基础上对请求进行二次签名。

比如每次请求带一个时间戳+随机字符串当 token,APP 把 token 当密钥,APP 内置 API 版本算法将请求路径和请求参数算出一个签名加入到 headers 同时发送,服务器每次收到请求先验证时间戳,超过一定时间直接拒绝,然后根据请求内容验证 token,不对也直接拒绝,这样有人抓包了也不能重放,想修改参数就必须得破解 APP 拿到加密算法。

每一个 API 版本都用不同的加密算法,要换算法直接禁 API 就行了,淘汰的 API 统一返回升级提示强迫用户升级 APP。
chotow
2019-11-13 07:50:39 +08:00
加密见其他楼层,我这里想到的是,用错误 token 请求接口时,不要返回报错,而是错误的内容,随机返回
xuanbg
2019-11-13 08:01:56 +08:00
楼主的需求是保护 API 不被盗用,这个说到底是没有万全的办法的。因为你不能确定用户来源,那么一切都只能是 open 的,也就意味着任何人都可以合法访问。

唯一有效的办法是搞个 IP 黑名单,然后监控流量,流量异常的拉黑就是了 。
eason1874
2019-11-13 08:09:39 +08:00
#14 补充一点。如果怕破解的人用自动工具通过 APP 一个个发送请求抓数据,那 APP 就再内置一个内容解密算法,和请求 token 转换内容密钥算法,APP 每次请求都把 token 转换成内容密钥一起传入回调处理用来解密返回的内容,服务器收到合法请求把 token 转换成内容密钥把响应内容加密返回,只返回加密内容就够了。
elarity
2019-11-13 08:46:14 +08:00
@witcat 既然是如此,我仔细琢磨了下,我觉得你需要的就是密钥协商。。。
kangzai50136
2019-11-13 10:02:30 +08:00
C++写,java 层调用?

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

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

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

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

© 2021 V2EX