逻辑漏洞之支付漏洞

支付漏洞案例分析

支付漏洞

乌云案例之顺丰宝业务逻辑漏洞

案例说明

顺丰宝存在支付逻辑漏洞,可以允许用户1元变1亿元。这个漏洞在其他网站很难存在,原因是页面交互都使用了对字段做签名。但是顺丰宝没做签名,导致支付金额可以被修改为任意数值。猜测成因是开发人员为了快速实现功能,而忽略了其中数据签名的步骤。可以想象,如果我充值1个亿,然后再使用取款功能,会产生神马效果。

利用过程

1 登录顺风宝查看余额


2 充值,选择招商银行。填写充值金额1,如下图:


提交之后如下:


3 开启firefox的tamper,点击支付,截取数据包,修改参数Amount为一分


4 提交跳转到招行支付


5 支付成功后,招行扣去一分


6 查询余额



乌云案例之乐视商城逻辑支付漏洞

案例说明

订单的价格在支付链接中出现,导致用户可以修改任意金额购买产品

利用过程

1 下单后选择支付,如图:


2 注意下面的连接,orderPrice参数为商品总额


3 将价格改成0.1



乌云案例之读览天下支付逻辑漏洞

案例说明

通过替换支付订单号的方式,来完成花小钱买大东西。同时生成两个订单号,一个贵的一个便宜,首先支付便宜的,银行往回返回的时候,替换订单号,然后就可以完成两个订单的同时支付。

漏洞成因

服务端只检查支付是否完成,并没有确认订单金额与银行支付金额是否相同,过分信任客户端提交的数据

修复方案

检查支付完成后价格和买的产品的价格是一样的。

乌云案例之天翼云盘通支付逻辑漏洞

案例说明

天翼云-云盘通设计缺陷,可提交负人民币的订单。

利用过程

1 选择套餐如图:


2 提交订单然后我们抓包,将购买年限改成负数


3 提交数据包后如图:


乌云案例之药房网订单提交逻辑漏洞

案例说明

药房网订单提交存在逻辑漏洞可对企业造成经济损失

利用过程

1 生成订单


2 使用Burp截断数据包,修改运费为一元



3 提交数据包


乌云案例之淘美网绕过支付

案例说明

淘美网重置处存在逻辑漏洞,可绕过支付直接充值成功

经过测试发现支付成功后流程走至如下链接:

http://www.3need.com/index.php?controller=site&action=payok&out_trade_no=充值订单号

只要提供对应的充值订单号 就可以绕过支付直接充值成功。

利用过程

1 新注册个账号进行测试


2 账号余额0


3 我们去充值,这个过程用burpsuite抓包,金额随意写



4 抓到支付订单号然后构造链接:



5 直接访问这个链接


6 接下来美女信息随意看了,不够再充


乌云大神的修复方案

1 和银行交易时,做数据签名,对用户金额和订单签名。

2 敏感参数不要明文放在URL中

3 服务端效验客户端提交的参数

4 在服务端计算金额的时候,一定要判断是否为正数。

5 支付过程中加一个服务器生成的key,用户校验参数有没有被串改。

6 如果一定需要用URL传递相关参数,建议进行后端的签名验证

7 订单金额和充值接口返回的数据进行校验

8 提交订单时后台判断单价是否与数据库中相符,如不符则返回错误。

9 支付时应从服务器拉取数据,而不是直接读客户端的值!!


### 攻击原理与利用方式 支付逻辑漏洞通常出现在 Web 应用的支付流程中,攻击者通过篡改支付过程中的关键参数(如金额、商品标识、订单状态等),利用系统对这些参数的校验不严,实现非法获利。这类漏洞的核心在于业务逻辑设计上的缺陷,而非依赖传统代码执行漏洞。攻击者可以使用抓包工具拦截并修改支付请求中的参数,例如将商品价格从 100 元修改为 1 元,从而完成低价购买高价商品的操作[^1]。 在某些支付接口中,由于多个支付平台的参数值不同,攻击者可以通过修改支付接口标识(如将支付宝接口修改为微信支付接口)来干扰支付流程,甚至尝试将支付接口替换为不存在的接口,观察系统是否仍然返回支付成功的结果。这种攻击方式依赖于支付接口逻辑处理不严格,攻击者可以利用系统对异常情况的默认处理策略进行绕过[^2]。 此外,支付漏洞也可能与业务逻辑的其他部分相关,例如订单状态更新、退款流程、优惠券使用规则等。攻击者可以通过多次提交订单、篡改订单 ID、重复使用优惠券等方式,绕过正常支付流程,达到非法获利的目的。这类漏洞通常难以通过传统的安全设备检测,因为攻击行为本身看起来是合法的,只是利用了业务逻辑漏洞[^3]。 ### 常见攻击场景与代码示例 在支付流程中,攻击者可以使用 Burp Suite 等抓包工具拦截支付请求,并篡改关键参数。例如,一个典型的支付请求可能如下: ```http POST /pay HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded product_id=123&price=100 ``` 攻击者可以将 `price=100` 修改为 `price=1`,然后发送修改后的请求,试图以 1 元完成支付。如果服务器未对价格进行严格校验,则可能接受该请求,从而导致经济损失。 在涉及多个支付平台的场景下,攻击者可能尝试将支付平台标识篡改为其他值,例如: ```http POST /pay HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded payment_method=alipay&amount=100 ``` 攻击者可以将其修改为: ```http POST /pay HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded payment_method=nonexistent_platform&amount=1 ``` 如果系统未正确处理不存在的支付平台标识,可能会返回支付成功的状态,从而让攻击者获得非法利益。 ### 防御策略 为了防止支付逻辑漏洞,开发人员应在服务器端对所有关键参数进行二次校验。例如,在支付接口中,不应仅依赖前端传入的价格,而应从数据库中获取商品的原始价格,并与传入值进行比对。同时,应使用加密签名机制对请求参数进行签名,防止篡改。 以下是一个简单的参数签名验证示例: ```php $expectedSignature = md5($productId . $originalPrice . $secretKey); if ($receivedSignature !== $expectedSignature) { // 阻止请求 die('Invalid request'); } ``` 此外,应避免直接使用用户提交的订单 ID 或支付平台标识,而是通过服务器端维护的状态机来控制支付流程,确保每一步操作都符合业务逻辑。对于优惠券、积分等系统,也应限制其使用次数和范围,防止被滥用。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值