ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Race conditions:Multi-endpoint race conditions

2026/10/1 19:45:55 拓冰建站 浏览量
Race conditions:Multi-endpoint race conditions 本文为博主原创文章未经作者授权禁止任何形式的转载。一、漏洞原理这道题的漏洞场景是当我们下订单时点击页面的“Place order”按钮服务器的处理逻辑其实包含两个子过程第一个过程是比较个人账号余额和购物车中的商品价格总额如果个人账号余额大于商品价格总额那么可以正常进行后续的支付流程如果个人账号余额小于商品价格总额那么无法完成后续的支付并且前端会有明确的报错提示第二个过程是对购物车中的所有商品进行支付。那么问题来了我们可以先在购物车中添加总额低于个人账号余额的商品绕过服务器对个人账号余额与购物车商品总额的比较后再往购物车中添加其他商品那么就可以达到用小金额额外购买商品的目的。二、漏洞证明1、使用burpsuite抓包找到将商品添加至购物车的http请求接口是/cart如下图2、使用burpsuite抓包找到生成订单并且支付订单的http请求接口是/cart/checkout如下图我们也可以看一下如果个人账号余额不足以支付购物车中的所有商品时前端页面会出现报错提示如下图3、默认的个人账号余额是100美元我们先往购物车添加价格总额低于100美元的商品确保1个人账号余额小于购物车中所有商品的价格总额2点击“Place order”按钮后可以正常支付。我的购物车商品如下4、将/cart和/cart/checkout两个接口发送至Repeater模块并放在同一个组中这里采用默认组名Group1如下图所示5、将Group 1中/cart接口的参数productId值改为1代表的含义是我们要把Lightweight L33t Leather Jacket这件商品添加至购物车/cart/checkout接口不做任何改动。/cart接口的修改如下图6、选择发送方式“Send group in parallelsingle-packet attack”攻击结果分为下面两种情况1/cart请求在校验余额后但是支付订单前被处理那么攻击成功我们把指定商品添加到了购物车并且不用花钱就下了单如下图支付成功后余额变为负数如下图2/cart请求在校验余额前就被处理或者在下单后才被处理那么攻击失败。三、漏洞思考1、这道题的下单流程包含两个步骤一是校验余额是否充足充足的情况下才允许下单二是使用余额完成支付。现实场景下的下单支付可能也有类似的流程思路值得学习。