【海外SRC实战】一个支付逻辑漏洞，怒赚 $9000 赏金

原创 Milad Safdari Z2O安全攻防 2025-05-13 13:33

前言

去年，我读了一些关于企业急于采用最新技术时发生的不安全实施的文章。众所周知，正确实施安全性总是昂贵且耗时的。这里的要点是，大多数开发人员在集成新技术时并没有完全阅读整个文档。有时，一个段落甚至一个句子都会使整个系统变得脆弱。

通过关注这些被忽视的细节，我们可以发现其他人多年来遗漏的漏洞。

国外白帽小哥在一次渗透测试时，发现目标网站使用了第三方支付服务-PayU，于是小哥开始对该支付服务进行漏洞挖掘，先后尝试了常规漏洞测试、双重消费、条件竞争等，毫无意外，均告失败。

重大发现

小哥并没有被失败轻易击倒，调整心态后，他开始阅读 PayU 的文档，并观看了一些 YouTube 教程，并将过程中的关键点做了一一记录。

通过这些过程以及关键点，白帽小哥开始思考：

“如果开发者错过了这个步骤会怎样？”

经过几周对 PayU 的分析，小哥测试了不同的场景，直到找到下面这个有趣的漏洞：
1. 首先，小哥将一些产品放入购物车，然后会被重定向到 PayU 的支付网关

重定向 PayU

注：在此之前，小哥购买了一个便宜的产品来查看系统如何处理支付过程
1. 当取消订单时，PayU 会将 URL 重定向回目标网站，并附带了一些 URL 参数：

修改参数
1. 正如上面抓包截图所示，如果将 status 参数修改“Succeed”，并用之前成功交易中的 payment_id 进行替换

订单确认

白帽小哥立即报告了该漏洞，一天之内漏洞便得到了修复，小哥因此获得了 3000 美元的赏金奖励。

其他商店也很容易受到攻击，因为它们的开发人员遵循了同样有缺陷的实现。通过在不同平台上利用同一个问题，小哥总计获得了 9000 美元的赏金奖励。

为什么这个漏洞存在这么久？

这不是一个容易找到
的。
小哥花了多次测试，甚至每次测试花费大约 1-2 美元
购买产品只是为了实验。许多黑客可能在过去 10 年中
测试了这个系统，但由于没有持续足够长的时间
而错过了漏洞
。

通过在
小哥的本地主机中实现相同的设置
，
小哥意识到了这个问题：
– 创建订单后，商店会等待 PayU 的回复
，然后再确认购买，并且不允许创建另一个订单。

如果响应包含状态为“成功”
的有效payment_id
，则目标系统将确认订单
而无需使用 PayU 内部验证该payment_id实际属于哪个订单！

这个看似“容易”的漏洞
我花了三个月
的时间才发现。但在那三个月里，我学到了很多
东西。

有些人可能会说，“你应该只关注这个漏洞，你本可以更早地发现它！
但请记住：
漏洞赏金计划就是测试数千个功能
，直到其中一个功能中弹
。

建立了一个
src专项圈子
，内容包含src漏洞知识库
、src挖掘技巧
、src视频教程
等，一起学习赚赏金技巧，以及专属微信群一起挖洞

圈子专注于更新src相关：

1、维护更新src专项漏洞知识库，包含原理、挖掘技巧、实战案例
2、分享src优质视频课程
3、分享src挖掘技巧tips
4、小群一起挖洞

图片

原文地址：https://eulex.medium.com/how-i-made-9-000-in-one-month-from-bug-bounty-9403147b4d07