记录第二次“梅花三弄”的渗透之旅

前言

最近一直在挖各大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沟通了一下，表达了上面的一些想法（原谅里面的一些错别字）

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

转自: Asaika