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

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

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

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

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

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

你玩成花照样可以爬你

爬你的收益大于爬你的成本就会被爬
防御爬虫的成本大于被爬的损失就不用反爬


我感觉有些还是难爬的 除非你说上真机 ocr 识别

先说下目的，为啥花这么大精力去加密？不加密会怎么样？
既然你 h5 和小程序可以不加密，那就从这里突破就好了

http 也可以加密，把 http 当成外层协议，相当于每次 http 请求只 post 加密的二进制数据。


那整体的接口安全还是要做的把，比如你总不能就弄个 https 裸奔把
微信账号还是挺费钱的 就算它用群控微信的软件来登录爬你数据，我感觉爬虫方还是挺费钱的


h5 跟小程序需要授权登录 一个账号还是难爬多少数据的
一些核心功能可以提示去 APP 操作


那纯 h5 页面 js 都是可以看的到的，你加密成二进制的 js 代码就算再怎么混淆 别人也是可以执行的。这样在 h5 端的 js 里加密不就失去意义了吗
实在麻烦，人家直接启动一个无头浏览器


防止一些爬虫跟一些脱机脚本

所有客户端程序都是这样啊，难道其它 C/Java 不是这样吗？无非就是提高破解成本，人家有心，肯定能破解。


所以现在才咨询有无一套比较好的通用方法 能限制一些脚本小子

去想什么攻击和防御方的成本收益不过是心里安慰而已；无救济便无权力，加密并不能提供什么真正的反制措施，所以我建议楼主做好用户实名认证和基于验证码的流量控制……

把 H5 砍掉 /引导到小程序，核心功能全塞进小程序里，限制微信登录+短信验证获取短效 api 令牌，限制单 ip 单位时间内请求数，ban 掉来自所有机房的 ip 。
最后说一句，其实把内容用 base64 还是什么偏门算法编码一下就能拦住 95%以上的傻屌，剩下的 5%不管上啥手段只要有利可图都没用。


我很好奇 比如像阿里 头条这些厂，他们这一块谁负责的
单独的业务安全部门 还是风控部门

数据内容 SSL 证书加密然后 base64 发送， 客户端 h5 公钥证书和解密用 c++做成 WebAssembly， 直接用这个解密。app 公钥证书和解密部分做在原生里面，webview 数据达到通过原生解密，在给页面。 小程序就不知道能不能用原生做解密插件了。

道理是这么回事...实际上...都是试着写过爬虫了, 才知道收益比吧

能阻止爬虫的只有法律

然而并不能

我的经验给我的判断是不可能存在这样一套机制，因为别人永远可以伪装成正常用户。而且这样也是没有必要的，大部分爬虫根本用不到这么复杂的机制就可以拦截了。我真得好奇什么样的内容值得这么去防护？

加密不能防爬虫，请做验证码、频率限制、行为识别

实现自有协议就爬不到了

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

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

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

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

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

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


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


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

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


一般人也没胆去搞银行吧

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

可以抓路由器的。

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

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

还是做用户风控稳妥

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


请教下 除了像 ssl pinning 来限制中间人攻击 还有什么更强大的方法拦截中间人攻击
人机判定的话 应该是一个更大的系统了

就我自己做爬虫到现在的经验来看, 只要你开放 web 页面, 就没有办法通过技术手段阻止别人获取你的数据了. 最后你能依靠的只有频率限制.
网站本身确实可以增加一些逆向工程的难度. 包括在前端实现 api 加签加密逻辑, 并且通过 javascript 而非序列化 api 结果返回必要参数, 然后把 js 本身混淆, 打乱变量, 让对方必须运行 js 虚拟机而没法用正则匹配你的参数. 但是如果你的数据真的有价值, 拿别人总能花时间逆向出来的. 这个时间通常也不会太长, 网站不可能频繁更新来抵御这种逆向过程.
最后还是回到用户的风控上来, 频率限制虽然古老但是有效. 当你账号的成本高的时候, 频率限制就是对方爬取你资源时不可回避的成本付出. 用户行为识别就是个升级版的访问限制攻防战, 你为了要服务正常用户不可预知的许多行为, 在这场攻防里是劣势, 对方最终一定有一条完美符合正常用户行为的行为方式. 只是正常用户行为通常会比你的古老频率限制请求更少资源, 所以有价值去做.
最后还得看你的内容本身多有价值, 值得你或者爬取者付出多大的代价来保护 /破解.

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

这位老哥说的好。

你当脚本小子是什么了，前端浏览器加密混淆一下除了拿工资的不会有别人闲的蛋疼搞你了。

这个就不懂了