前端保护 API 接口用的是什么技术？

[LeeReamond]

在首页大麦网抢票贴里看到如下一条回复：

“简单说走接口抢的，可能没研究过大麦，用的阿里的那一套技术，风控 。正常想要抓到接口都难，更不要说模拟出来了。。。省略之后若干字”

OP 没怎么研究过渗透相关的技术，想问下接口都抓不到的情况真的存在吗？用什么技术实现的，还挺好奇的

[Drumming]

大麦抢票也可以直接走接口跳转，类似淘宝京东 BP 链接
没那么复杂，信息差和一点技术门槛就足够拦住大部分人了
不存在抓不到的接口，如果有那就上逆向

[guguji5]

https 能拦住一部分人

[Dawnnnnnn]

我记得通讯是 spdy 协议的，不是普通的 http 协议，抓包难度挺大

[jinliming2]

各种技术的综合吧，简单的比如接口加混淆参数，前端代码混淆，这样可以提高门槛。
另外就是服务端做风控，举个例子，比如你访问网站的时候给你下发一个看起来没用的 cookie ，接口提交的时候没有这个 cookie 貌似也可以成功，但服务端已经知道接口请求不正常了，就会“以让你看起来正常的方式”失败，比如还有票，就给你说票没了，或者降低你这个接口的权重，票量充足就成功，票不足的时候优先让给其他用户。如果一直用这样的方式来发请求，就会把账号标记为黑号等。
当然，也不一定是用 cookie ，也可以用行为，比如正常操作抢票的话，会按顺序调用哪几个接口，但到你这里没有这些前序步骤了，也会标记为不正常。

[oppoic]

@jinliming2 补充一个：页面静态资源一个不调用就完成购票的，即可判定为爬虫用户

[yinmin]

多点探测，混沌封控。

1. 设多个探测点，例如：某个页面是否加载过、某个 css 是否加载过、某个图片是否加载过、某个貌似无用的 cookie 是否存在、localstorage 存些貌似无用的数据、页面加载的前后次序 等等。

2. 混沌封控，根据不同的场景(紧俏票、抢票时段) 票的查询接口、下单接口、付款接口有时拒绝、有时降低优先级、非抢票时段放行 等等。

写抢票软件的人在混沌封控状态下，会非常迷茫，无法提高抢票成功率，但又无所适从。

[letitbesqzr]

淘宝系 软件，部分核心接口是走的 spdy ，以前有提供开关，hook 函数以后可以关闭。

难的其实还是风控部分，可以参考一些商用产品的做法，实际上还是在各种混淆。

提供一个例子，南航官网[https://www.csair.com/cn/]的机票查询接口 （注意查询接口 cookie 中的 acw_tc 、ssxmod_itna 这部分内容）

目测应该是用的阿里云 waf 里的“场景防护 BOT 管理” 参考： https://help.aliyun.com/document_detail/434071.html

[Biluesgakki]

既然这么困难 那些黄牛到底咋抢的票。。

[totoro52]

@Biluesgakki 中国特色抢票

[liuxu]

他这句话是在说我的回复，我懒得搭理他

难度总是有的，但守方永远是被动方，误判也多，比如我用 gentoo+chrome 访问淘宝，登录账号后还是几个页面弹一个验证，同时间段换 win11 没什么问题

前端保护 api 也就能防防新人，正常的搞法就是 wireshark 抓包识别协议 + js 逆向，找出关键变量和接口，提前 2 分钟从网页获取 session/token 之类的关键变量，写程序把变量填上，csrf 之类的程序跑起来代码获取，然后对所有请求进行流量重放

上面的方法是抢黄牛的票，他们都是程序搞的，抢普通人的票用 autojs/油猴搞自动流程点击也行，这种只能抢 3 秒都抢不完的订单，毫秒级秒杀类还是得按上面的来，抢毫秒级的也可以找接口的服务器节点，买同地域的服务器开脚本，有 ip 风控也可以用加宽代理，再不行自己家台式机改光纤口，不走路由器直接光口出请求都可以

所以这些除了黄牛有灰产产业链拿钱支撑维护程序，正常人才懒得搞，随便换个参数就要重新来一遍改程序

[hhjswf]

接口不是关键吧，关键接口里头的参数不是那么容易弄到

[IvanLi127]

他也没说抓不到呀，只说难抓。
不可能抓不到包。要是抓不到，那抢票的名额都没给你，直接前端自己处理了。。。

[jin7]

@jinliming2 @yinmin @letitbesqzr @liuxu @hhjswf @IvanLi127
这边测试说删除操作不让 url 传参, POST /delete/1 或者 POST /delete?id=1 这样都不行, 让把 id 放到 body 里面
这样真的安全一点吗? 放 body 里面就看不到了吗?

[liuxu]

@jin7 放 param 里是常规操作，放 body 可能触发一些软件的 reject ，相关问题你可以看下 rfc： https://www.rfc-editor.org/rfc/rfc7231#page-29

https 都安全，http 都不安全

[IvanLi127]

@jin7 自欺欺人罢了。会安全一点还是不安全一点，那就不好说了。毕竟奇怪的操作越多，别人就看着迷糊。迷糊住了攻击者还是自己人就不好说了

[yinmin]

出票后端弄一个公平抽签算法：每 0.5 秒间隔的所有购票请求汇集在一起，然后随机抽签给票，一个手机号每 5 秒只能抢一次，前 15 秒人人都有机会参与。不是抢速度，而是看运气，不至于黄牛抢到过多票。

[jinliming2]

@jin7 #13 如果在没有其他安全措施的情况下，那么放在 body 里，并且不接受 application/x-www-form-urlencoded 或者 multipart/form-data 作为 body 的话，而是使用类似于 application/json 之类的，可以在一定程度上防 CSRF ，因为即便是 POST ，符合简单请求 simple request 条件的话，也是不会进行 preflight 预检的。