前言

最近一直在挖各大SRC厂商的逻辑漏洞,以前听别人说过有些支付漏洞因为其业务流程的原因,会被厂商忽略,没想到自己竟然也遇到了相同的事情2333,接下来我将详细介绍挖洞过程和忽略原因。

挖洞过程

梅开一度

首先进入某网站,注册一个账号。关于注册方面的逻辑漏洞,似乎前辈们已经挖的渣都不剩了,经过一通测试,只能选择放弃。由于这是一个购买服务类型的网站,结下来要测试的逻辑漏洞当然就是支付漏洞。

我任意输入了一些关键词进行搜索,选择了一个价值7000的商品,点击进入购买。

进入商品后,点击购买,进入购买界面。

点击下单,使用Burp Suite进行抓包

在抓包的过程中看到了一个关于amount=7000&orderAmount=7000的参数项,将两个参数同时进行修改成1,目的是为了使其价格变成一元,然后放包。

在放包后,可以看到起GET头部传输的参数中amount=1.00,挖到这里觉得里成功已经不远了。

接下来继续放掉数据包,知道放完所有的数据包后,看到了想要的结果,支付金额从7000元变成了1元。

当时心中觉得这是已经成功了,不过前人的经验告诉我,虽然将支付金额修改了,生成了一个支付账单,但也可能在支付的时候出现无法支付的情况。我冒着破费一块钱的风险支付了一下,结果成功了55555。

当时看到这里,心想一个紧急漏洞又到手了。为了确保万无一失,我还特意去订单里看了一下,是否有支付成功的记录。

没错,的确支付成功了,与下面同样修改了价格但没有支付的订单相比,该订单已经支付,待服务商家接单。于是乎我高高兴兴的把漏洞挖掘的整个过程详细地写成报告,提交到他们的SRC官网上。

梅开二度

不到半天功夫后,看到他们漏洞审核回复,发现竟然是忽略,当时整个人瞬间心凉了。于是乎我去看了他们的回复

就这简短的几句话,我竟毫无理由反驳,这难道就是不熟悉业务流程而导致徒劳无功?不一会,他们的SRC客服加了我的微信,我就此事对他们的评价提出了质疑。

他们的SRC安全中心的官方文档中有说明存在支付问题,而他在这里给我的解释就是他们之前已经发现了这个问题。对你没有看错,他们之前就发现了这个问题,然后一直没有改。

因为以前也听说过类似的事情,所以也没怎么跟他钻牛角尖,后来自己想了一下其中的一些潜在问题。

  1. 这种p2p模式的交易商店有两重支付确认,第一就是你需要通过正规流程进行支付,其次就是在支付完成后,店家需要进行价格二次确认,才会提供服务,在服务完成后,买家对服务的整体做二次确认验收成果后才会付款到卖家。

  2. 这个过程中影响付款金额的推进有两处,第一处就是卖家针对买家的支付价格是否确认接受服务,(正如他们的SRC客服所言,我购买的服务到现在都没人接单)也就是说只有这个支付价格在卖家的接受范围内,他们才会考虑是否接单。

  3. 针对本次服务,它的原本价格是7000,我将它改为1元,这落差价格确实太大了,按照他们网站的业务服务流程,卖家接单基本是不可能的事情,除非它是真的眼瞎。那么,如果我通过价格修改,将其产品服务的价格修改成6999元,卖家会接单服务吗?然而我并没有冒这个险去尝试,话说我那支付的一块钱到现在都没有退给我55555。

在写这篇文章的时候,还没有就这个逻辑思路跟他们的SRC客服沟通,估计被驳回的可能性非常大,因为他们自己都说早就发现这个漏洞了,只是他们没修,觉得可能花钱修也没必要。

梅花三弄

抱着对解决事情的严谨态度,(其实是挖漏洞太难了,尤其是支付这种紧急的漏洞555)我再次跟他们的SRC沟通了一下,表达了上面的一些想法(原谅里面的一些错别字)

没错,还是维持原判,一句谢谢大佬结束了对话,我太难了

点击收藏 | 0 关注 | 1
登录 后跟帖