文章总结： 本文深入分析Web安全中的多端点条件竞争漏洞，重点探讨电商场景下通过并发操作购物车与支付端点实现低价购买高价商品的攻击手法。文档详细描述了漏洞原理、利用步骤及PortSwigger实验案例，揭示缺乏事务锁时产生的竞争窗口风险，并提供具体的漏洞复现方法。 综合评分： 88 文章分类： 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安全之多端点条件竞争漏洞》