上期回顾我们学会了骗验证码、骗密码重置。本期是业务逻辑漏洞的“重头戏”——支付。俗话说“常在河边走哪有不湿鞋。” 做支付的厂商十个里有九个在金额校验上栽过跟头。一、支付漏洞的核心本质信任客户端。服务器说“我相信你前端传过来的价格是 99 元那它就是 99 元。”结果你抓包改成 0.01 元服务器也认了。这就叫巨款流失。二、修改参数的“四两拨千斤”1. 价格篡改Price Manipulation场景购买商品数据包如下httpPOST /createOrder HTTP/1.1 { product_id: 1001, price: 1999, // 原价1999 count: 1 }操作用 Burp Suite 拦截把price: 1999改成price: 0.01。结果花 1 分钱买走 iPhone。SRC 提示高危直接修改成功且发货。中危修改成功但未发货需要人工审核。无效后端校验了数据库里的真实价格。2. 负数与零元购Negative Values这是很多新手容易忽略的。场景充值话费。Payloadjson{ amount: -100 }发生了什么如果后端没校验正负你充值 -100 元账户余额增加​ 100 元。甚至有的系统支持0.001元购买利用精度丢失漏洞。3. 数量逻辑Quantity Logic场景商品单价 100 元限购 1 件。操作修改count1为count9999。如果后端只在前端限制了“限购”你会买到破产。三、并发竞争Race Condition进阶必杀技这是目前 SRC 里最难挖但也最值钱的逻辑漏洞。1. 什么是并发想象一个超市收银台你只有 100 块钱但你想买 10 件 100 块钱的商品。你同时派 10 个朋友去结账。收银员还没来得及扣完你的钱10 个朋友都已经把钱付了或者没扣成。结果你用 100 块买了 1000 块的东西。2. 实战案例提现“无限刷”场景用户余额 100 元。接口/withdraw?money100正常流程检查余额 100。扣减余额。发起转账。漏洞点如果在第1步​ 还没执行第2步​ 的时候再次发起请求会怎样操作Burp Suite Intruder抓取提现请求包。发送到Intruder设置Null payloads生成 50 个请求。设置Resource Pool​ -Maximum concurrent requests: 20并发 20 个。开火结果如果后端没加数据库锁Transaction你会发现余额变成了-900但你收到了 1000 元的转账。3. 兑换码并发场景你有 1 张优惠券。操作并发 50 次兑换请求。结果1 张券变成了 50 张券。四、签名绕过Hash 碰撞现在很多支付接口会用sign签名来验证参数是否被篡改。数据包json{ price: 100, sign: md5(secret_key price) }绕过思路空签名尝试删除sign参数。弱密钥如果secret_key是123456尝试暴力破解。数组绕过有些系统在解析price[]100时签名校验通过但支付时当作 100 处理。五、SRC 报告撰写指南漏洞描述厂商看法评级修改价格为 0 元严重立刻修复Critical​并发提现导致余额为负严重资金损失Critical​修改运费为 -10 元中危影响较小Medium​报告话术“由于支付接口未对负数金额进行有效校验且缺乏并发锁机制攻击者可利用 Race Condition 实现零成本购造成厂商直接经济损失。”六、互动与思考 互动话题大家还见过哪些奇葩的支付逻辑比如买东西送钱或者退款金额大于付款金额欢迎在评论区分享记得打码。⚠️ 法律红线警示严禁利用支付漏洞进行真实的0元购、盗刷或非法获利。这构成盗窃罪是要负刑事责任的严禁利用并发漏洞恶意刷光厂商资金池。测试原则使用0.01元​ 或1分钱​ 进行支付测试。如果测试成功立即取消订单或联系客服退款不要收货。不要尝试提现到自己的银行卡。靶场练习请在Vulhub​ 或PentesterLab​ 的支付靶场中练习并发攻击。君子爱财取之有道。用你的技术帮厂商堵住漏洞而不是钻漏洞。​ ️下一期我们将进入“越权访问IDOR—— 隔壁老王的故事”。想知道怎么看别人的私密照片吗敬请期待