文章总结： 该文档详细分析了Web安全中的多端点条件竞争漏洞，指出其通过并发操作多个API端点绕过业务限制的特性。以电商系统为例，演示了攻击者如何利用购物车写入与订单支付间的时序差异，以低价商品支付流程偷渡高价商品。文档包含完整的漏洞复现案例，展示了从检测竞争窗口到成功利用的全过程，并隐含了加强后端事务锁与状态校验的防护建议。 综合评分： 85 文章分类： WEB安全,漏洞分析,实战经验,红队,安全开发

web安全之多端点条件竞争漏洞

原创

流岁金沙 流岁金沙

迷雾光航

2026年5月15日 14:42 浙江

在小说阅读器读本章

去阅读

web安全之多端点条件竞争漏洞

简介

• 多端点条件竞争（Multi-Endpoint Race Condition）是条件竞争的一种更复杂、更隐蔽的形态。

• 普通条件竞争：单一请求入口，多个并发请求操作同一接口

多端点条件竞争：攻击者操作的是多个不同的API端点，这些端点之间存在业务逻辑依赖，通过精心设计的并发请求组合，实现绕过原本独立的业务限制

常见情况分析

低价买高价的物品

在部分电商系统中，如果后端对“购物车写入”和“订单支付”之间的状态校验处理不严谨，就可能出现一种典型的条件竞争（Race Condition）问题。 攻击者可以利用请求执行顺序的不一致，在支付阶段“偷渡”高价商品，从而以低价完成购买

正常情况下，一个完整的购买流程通常如下：

添加商品到购物车
↓
后端写入数据库
↓
提交订单
↓
校验订单金额/商品合法性
↓
支付订单
↓
清空购物车

但如果后端采用了：

• “先确认订单”

• “再执行支付”

• “最后清空购物车”

这样的逻辑，并且缺乏事务锁或状态隔离，就可能产生竞争窗口。

漏洞利用思路

攻击者首先：

1. 向购物车中添加一个低价商品
2. 在结算瞬间，并行发送两个请求：

• 一个是添加高价商品

• 一个是提交订单/支付

由于并发执行，请求的实际执行顺序可能变成：

[线程 A] 开始支付订单
↓
[线程 A] 校验订单金额（此时购物车仍是低价商品）
↓
[线程 B] 写入高价商品到购物车
↓
[线程 A] 继续执行支付逻辑
↓
订单中已包含高价商品
↓
完成支付

案例复现

https://portswigger.net/web-security/race-conditions/lab-race-conditions-multi-endpoint

首先添加10美元的礼品卡到购物车，然后支付订单，查看这个流程的数据包和响应时间

支付的响应时间明显比添加商品的响应时间要久一点，说明很可能会出现竞争窗口

重新添加10美元的礼品卡到购物车，然后并发发包添加第一个1337美元的商品和购买的数据包

成功购买1337的商品，并且余额变成了负数

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：迷雾光航 流岁金沙 流岁金沙《web安全之多端点条件竞争漏洞》