关于 API 接口安全的思考，感觉 H5 端不好做，是不是各大厂主推 APP 也是这么考虑的

[0576coder]

假如一个产品包含 H5 端、小程序、APP 端三端。 小厂为了方便，肯定三端会有一些公用的接口，那么自定义协议之类的肯定不能用，还得用 http 协议

那么问题来了，https 通过本地抓包的方式，还是能解析你接口里面的内容。为了防止别人爬你数据，脱机请求你接口。API 的安全其实是非常重要的。对此 我有如下想法，不知道大家有无更好的 idea

首先分两步，h5 、小程序只允许比如微信授权登录的用户进行操作，接口可以不加密，但是用户的登录凭证不要设置太长。

第二步 APP 在用户启动的时候进行一种密钥交换算法，通过后端动态安全的下发密钥。可以参考 Diffie-Hellman 算法 第二步，APP 后续与服务端通信的核心接口全走 aes-256 之类的对称加密方式传 sign 值给服务端，为了防止别人能够重放攻击，可以考虑 APP 与服务端维持一个长链，动态推送时间戳之类的方式，保证每次就算请求参数一样，加密出的 sign 值也是不一样的。

但是问题来了，密钥交换的时候如果别人猜出你的交换算法，也有可能导致中间人攻击，所以可以考虑 APP 内置一个 rsa 的公钥（不知道有无更好的方案）。 当然 APP 需要把这些东西封装成.so 文件，然后 APP 包再用付费的方式加固。这样应该能拦住百分之 99 的脚本小子了。

最后再加上一些实时的行为风控。比如用户访问过于频繁 或者浏览的内容超过正常人的量，可以动态的弹出图形验证码之类的做校验

[p1094358629]

实现自有协议就爬不到了

[finian]

你提到的 App 的做法就是重新发明了一次 HTTPS，「所以可以考虑 APP 内置一个 rsa 的公钥」这个就是 HTTPS 中的 SSL Pinning 做法。关键是，即使你 App 做了足够多的防御，其他两个端也很容易被嗅探，没啥用

[IvanLi127]

防爬得做风控限制，传输再安全也只是保证数据的安全性，数据加密人家可以抽程序出来解，做风控吧，服务端可靠多了

[meshell]

就像 #1 楼说得，玩成花照样爬你，我们上次做一个赛事数据，就是爬得别人的 APP，人家 app 加壳，.so 生成密钥。花点时间照样被拿下只是成本收益问题。

[LJ2010]

非对称加密不可以吗？终端公匙加密，API 端私匙解密

[xiaoding]

h5 也是得加密的，js 加密。这就是个无底洞，永远是攻防之间互相提高成本，最后谁受益小于成本了，谁就输了。

[guyeu]

做客户端吧，一体成型的振金外壳加上硬盘加密技术，应用程序的二进制（加密）放在 ROM 里， 前后端通信密钥协商+内存加密。

[0576coder]

@LJ2010
全非对称 比如你全部接口一条调用量一亿次 比较耗费服务端 cpu 的 非对称

[0576coder]

@finian
也是 感觉开启 ssl pinning 跟我那复杂的一套差不多效果 能破的还是能破

[eason1874]

SSL Pinning 证书固定，公钥固定，版本固定。想抓包，每个版本都得反编译拿到证书。有的银行 APP 连这点都没做。

[0576coder]

@eason1874
一般人也没胆去搞银行吧

[ychost]

反编译一下，就是裸奔，没办法说做到绝对的加密

[meshell]

@eason1874 可以抓路由器的。

[ch2]

你的 app 运行环境就是可靠的？系统级 hook 你的加密，根本不需要知道你的具体方法。数据被爬是不可避免的，只能拦住那些只想花几百块钱就搞定你接口的人

[reself]

要区别人机判定问题和中间人攻击问题，不要混在一起。
另外，算法公开影响安全性是伪命题。现在流行的加密本身就假设算法是公开且易知的，只需要保证密钥的安全性。

[feiniu]

还是做用户风控稳妥

[q197]

关键还是 app 怎么盈利，如果是靠广告，少数第三方客户端不影响大部分用户带来的收入。付费内容只要别做成前端判断就没事，有爬虫也不影响盈利。所以能防住大量爬虫请求浪费服务器资源就不错了

[0576coder]

@reself
请教下 除了像 ssl pinning 来限制中间人攻击 还有什么更强大的方法拦截中间人攻击

人机判定的话 应该是一个更大的系统了

[karloku]

就我自己做爬虫到现在的经验来看, 只要你开放 web 页面, 就没有办法通过技术手段阻止别人获取你的数据了. 最后你能依靠的只有频率限制.

网站本身确实可以增加一些逆向工程的难度. 包括在前端实现 api 加签加密逻辑, 并且通过 javascript 而非序列化 api 结果返回必要参数, 然后把 js 本身混淆, 打乱变量, 让对方必须运行 js 虚拟机而没法用正则匹配你的参数. 但是如果你的数据真的有价值, 拿别人总能花时间逆向出来的. 这个时间通常也不会太长, 网站不可能频繁更新来抵御这种逆向过程.

最后还是回到用户的风控上来, 频率限制虽然古老但是有效. 当你账号的成本高的时候, 频率限制就是对方爬取你资源时不可回避的成本付出. 用户行为识别就是个升级版的访问限制攻防战, 你为了要服务正常用户不可预知的许多行为, 在这场攻防里是劣势, 对方最终一定有一条完美符合正常用户行为的行为方式. 只是正常用户行为通常会比你的古老频率限制请求更少资源, 所以有价值去做.

最后还得看你的内容本身多有价值, 值得你或者爬取者付出多大的代价来保护 /破解.

[dsg001]

爬某个大厂的 app 端，内容加密，搞不定，转头抓包小程序，接口完全开放，啥验证也没