这是一个创建于 561 天前的主题，其中的信息可能已经有所发展或是发生改变。
在首页大麦网抢票贴里看到如下一条回复：
“简单说走接口抢的，可能没研究过大麦，用的阿里的那一套技术，风控 。正常想要抓到接口都难，更不要说模拟出来了。。。省略之后若干字”
OP 没怎么研究过渗透相关的技术，想问下接口都抓不到的情况真的存在吗？用什么技术实现的，还挺好奇的
 |
1
Drumming 2023-05-10 14:18:15 +08:00
大麦抢票也可以直接走接口跳转，类似淘宝京东 BP 链接
没那么复杂，信息差和一点技术门槛就足够拦住大部分人了 不存在抓不到的接口，如果有那就上逆向 |
 |
2
guguji5 2023-05-10 14:21:52 +08:00
https 能拦住一部分人
|
 |
3
Dawnnnnnn 2023-05-10 14:27:11 +08:00
我记得通讯是 spdy 协议的，不是普通的 http 协议，抓包难度挺大
|
 |
4
jinliming2 2023-05-10 14:32:33 +08:00 via iPhone  7
各种技术的综合吧，简单的比如接口加混淆参数，前端代码混淆，这样可以提高门槛。
另外就是服务端做风控，举个例子，比如你访问网站的时候给你下发一个看起来没用的 cookie ，接口提交的时候没有这个 cookie 貌似也可以成功，但服务端已经知道接口请求不正常了，就会“以让你看起来正常的方式”失败，比如还有票，就给你说票没了，或者降低你这个接口的权重，票量充足就成功，票不足的时候优先让给其他用户。如果一直用这样的方式来发请求，就会把账号标记为黑号等。 当然，也不一定是用 cookie ，也可以用行为，比如正常操作抢票的话，会按顺序调用哪几个接口，但到你这里没有这些前序步骤了，也会标记为不正常。 |
 |
5
oppoic 2023-05-10 14:49:31 +08:00
@jinliming2 补充一个：页面静态资源一个不调用就完成购票的，即可判定为爬虫用户
|
 |
6
yinmin 2023-05-10 16:09:54 +08:00
多点探测，混沌封控。
1. 设多个探测点，例如：某个页面是否加载过、某个 css 是否加载过、某个图片是否加载过、某个貌似无用的 cookie 是否存在、localstorage 存些貌似无用的数据、页面加载的前后次序 等等。 2. 混沌封控，根据不同的场景(紧俏票、抢票时段) 票的查询接口、下单接口、付款接口有时拒绝、有时降低优先级、非抢票时段放行 等等。 写抢票软件的人在混沌封控状态下，会非常迷茫，无法提高抢票成功率，但又无所适从。 |
 |
7
letitbesqzr 2023-05-10 16:41:48 +08:00
淘宝系 软件，部分核心接口是走的 spdy ，以前有提供开关，hook 函数以后可以关闭。
难的其实还是风控部分，可以参考一些商用产品的做法，实际上还是在各种混淆。 提供一个例子，南航官网[https://www.csair.com/cn/]的机票查询接口 （注意查询接口 cookie 中的 acw_tc 、ssxmod_itna 这部分内容） 目测应该是用的阿里云 waf 里的“场景防护 BOT 管理” 参考： https://help.aliyun.com/document_detail/434071.html |
 |
8
Biluesgakki 2023-05-10 16:44:26 +08:00
既然这么困难 那些黄牛到底咋抢的票。。
|
 |
9
totoro52 2023-05-10 16:49:58 +08:00
@Biluesgakki 中国特色抢票
|
 |
10
liuxu 2023-05-10 17:20:58 +08:00
他这句话是在说我的回复，我懒得搭理他
难度总是有的，但守方永远是被动方，误判也多，比如我用 gentoo+chrome 访问淘宝，登录账号后还是几个页面弹一个验证，同时间段换 win11 没什么问题 前端保护 api 也就能防防新人，正常的搞法就是 wireshark 抓包识别协议 + js 逆向，找出关键变量和接口，提前 2 分钟从网页获取 session/token 之类的关键变量，写程序把变量填上，csrf 之类的程序跑起来代码获取，然后对所有请求进行流量重放 上面的方法是抢黄牛的票，他们都是程序搞的，抢普通人的票用 autojs/油猴搞自动流程点击也行，这种只能抢 3 秒都抢不完的订单，毫秒级秒杀类还是得按上面的来，抢毫秒级的也可以找接口的服务器节点，买同地域的服务器开脚本，有 ip 风控也可以用加宽代理，再不行自己家台式机改光纤口，不走路由器直接光口出请求都可以 所以这些除了黄牛有灰产产业链拿钱支撑维护程序，正常人才懒得搞，随便换个参数就要重新来一遍改程序 |
 |
11
hhjswf 2023-05-10 17:21:20 +08:00 via Android
接口不是关键吧，关键接口里头的参数不是那么容易弄到
|
 |
12
IvanLi127 2023-05-11 09:55:00 +08:00 via Android
他也没说抓不到呀，只说难抓。
不可能抓不到包。要是抓不到，那抢票的名额都没给你，直接前端自己处理了。。。 |
 |
13
jin7 2023-05-11 10:20:44 +08:00
@jinliming2 @yinmin @letitbesqzr @liuxu @hhjswf @IvanLi127
这边测试说删除操作不让 url 传参, POST /delete/1 或者 POST /delete?id=1 这样都不行, 让把 id 放到 body 里面 这样真的安全一点吗? 放 body 里面就看不到了吗? |
|
14
liuxu 2023-05-11 11:54:00 +08:00
@jin7 放 param 里是常规操作，放 body 可能触发一些软件的 reject ，相关问题你可以看下 rfc： https://www.rfc-editor.org/rfc/rfc7231#page-29
https 都安全，http 都不安全 |
|
15
IvanLi127 2023-05-11 12:15:01 +08:00 via Android
@jin7 自欺欺人罢了。会安全一点还是不安全一点，那就不好说了。毕竟奇怪的操作越多，别人就看着迷糊。迷糊住了攻击者还是自己人就不好说了
|
|
16
yinmin 2023-05-11 13:22:25 +08:00 via iPhone
出票后端弄一个公平抽签算法：每 0.5 秒间隔的所有购票请求汇集在一起，然后随机抽签给票，一个手机号每 5 秒只能抢一次，前 15 秒人人都有机会参与。不是抢速度，而是看运气，不至于黄牛抢到过多票。
|
|
17
jinliming2 2023-05-11 20:21:58 +08:00 via iPhone
@jin7 #13 如果在没有其他安全措施的情况下，那么放在 body 里，并且不接受 application/x-www-form-urlencoded 或者 multipart/form-data 作为 body 的话，而是使用类似于 application/json 之类的，可以在一定程度上防 CSRF ，因为即便是 POST ，符合简单请求 simple request 条件的话，也是不会进行 preflight 预检的。
|
Select Language