毫秒级条件竞争：从购物车加塞到连接预热，赏金猎人的完整节奏

原创

升斗安全XiuXiu
升斗安全XiuXiu

升斗安全

2026年8月21日 07:45
广东

在小说阅读器读本章

去阅读

【文章说明】

• 目的：本文内容仅为网络安全技术研究与教育目的而创作。
• 红线：严禁将本文知识用于任何未授权的非法活动。使用者必须遵守《网络安全法》等相关法律。
• 责任：任何对本文技术的滥用所引发的后果自负，与本公众号及作者无关。
• 免责：内容仅供参考，作者不对其准确性、完整性作任何担保。

阅读即代表您同意以上条款。

多端点条件竞争：一场与时间赛跑的游戏

今天咱们来聊点刺激的：多端点条件竞争。别被这个名字吓到，说白了，就是“同一时间，多个请求一起上”，看服务器反应不过来的时候，能不能钻点空子。

举个最经典的例子：你在购物车里先放点东西，去付款，然后在系统还没最终确认订单之前，火速再往购物车里塞几件商品。听上去像不像在收银台结账时，趁收银员转身的瞬间往袋子里多塞两包薯片？道理差不多，只不过这里拼的是毫秒级的手速和对系统流程的熟悉程度。

如果你对这个套路还不太熟，建议先去看看“业务逻辑漏洞”主题里的“工作流验证不足”相关内容（关注我，在历史文章中可以找到），那里面讲得更详尽一些。

还有一种更隐蔽的变体：支付验证和订单确认是在同一次请求里一口气完成的。这时候，订单状态机大概长这样：

看到了吗？在“支付验证”和“订单最终确认”之间，存在一个极短的窗口期。如果你能在这个窗口里再往购物车里加点东西，系统可能就稀里糊涂地给你一起确认了。

怎么把两个窗口“对齐”？

做这种测试时，哪怕你已经用了单数据包技术，把所有请求同时发出去，也可能会发现：每个请求的响应时间还是对不齐。就像你想让两个人同时起跑，但一个人的起跑器卡了一下，另一个已经冲出去了。

造成这个问题的原因主要有两个：

• 网络架构的延迟：比如前端服务器要跟后端新建连接，或者用的协议本身就慢半拍。
• 端点自身的处理延迟：不同接口干的事不一样，有的快有的慢，差距还挺明显。

不过别慌，这两个问题都有办法对付。

连接预热：先让跑道热起来

后端连接的延迟一般不会搞砸你的攻击，因为它对所有并行请求的拖累是差不多的，相当于大家一起慢半拍，节奏还是稳的。关键是要分清哪些延迟是网络造成的，哪些是接口自己磨蹭。

一个简单的方法：先发几个无关紧要的请求“预热”一下连接。比如在 Burp Repeater 里，你可以在请求组最前面加一个对首页的 GET 请求，然后用“按顺序发送组（单一连接）”的方式跑一遍。

如果第一个请求还是慢吞吞，但后面的请求都被压缩到一个很短的时间窗里处理完了，那说明这个延迟可以忽略，你直接正常测就行。

要是你发现，哪怕用了单数据包技术，同一个端点的响应时间还是忽快忽慢，那多半是后端延迟在捣乱。这时候可以试试用 Turbo Intruder，在发送真正的攻击请求之前，先塞几个预热请求进去，把连接“喂饱”，再动手。

竞争条件的玩法远不止这些，但万变不离其宗：找窗口、对时间、钻空子。如果你觉得这篇文章对你有帮助，别客气，点个赞，点个在看，转发给一起挖洞的兄弟们。也欢迎关注我，后面还会继续分享更多实战中的骚操作和踩坑经验。咱们下篇见！