【逻辑漏洞】-第四篇-支付漏洞

漏洞介绍

众所周知，在线购物已经逐渐成为现今社会的主流消费方式，因此电子支付已经成为现代生活中不可或缺的支付方式之一。然而随着电子支付的普及，支付系统也成为黑客攻击的目标之一。而支付逻辑漏洞就是其中一种被黑客利用的攻击手段。

支付逻辑漏洞是指支付系统中存在的一些安全漏洞，这些漏洞可能导致黑客通过篡改、伪造或者其他手段绕过正常的支付流程，从而非法获取财物或资金，给支付系统带来极大的安全威胁。因此，支付机构和用户都需要加强支付安全意识，防范支付逻辑漏洞的攻击。

漏洞成因

支付漏洞的成因，其实和越权漏洞有些类似，都是对客户端提交的数据过分相信，没有在后端进行进一步的校验。而他们的区别在于 越权漏洞是没有对数据或操作进行身份校验，而支付漏洞则是没有对数据本身的正确性进行校验（这里不讨论畸形数据引起的sql注入，xss，dos等问题）。

支付漏洞的利用方式有很多，具体和场景有关，这里主要介绍一些比较常见的利用：

修改价格：

这个是最基本的支付漏洞利用方式，是在生成订单或支付货款的过程中，直接抓包修改商品的价格参数。如果平台后端没有对价格参数进行校验就确认的话，就会被攻击者利用。

举例说明🌰🌰，以下为一个生成订单的接口

POST /api/createOrder
Host: example.com

goodsid=1&price=500&number=1

这样一个接口，用以生成id为1的商品订单。那么如果这里存在修改价格的支付漏洞，攻击者就可以用burp抓包修改为price=0或负数，从而白嫖商品。

修改数量：

有的时候，某些商品会存在限购的情况（一个账号只能购买一件），在购买页面尝试增加商品数量时会失败。此时如果只是在前端对商品数量的修改做了限制，后端没有对相关参数再次进行校验的话，就会被攻击者利用。

还是以上面的 /api/createOrder 接口举例说明🌰🌰

如果这里存在修改数量的支付漏洞，攻击者就可以用burp抓包修改number参数的值，从而大量购买限购商品。

注：也可以通过高并发的方式实现此类攻击，具体原理可以参考系列第二篇 短信bomb漏洞。

修改商品id：

一般商城系统在上线之前，开发人员会放一些0元的测试商品在里面用于接口和功能的测试，但有时在系统正式上线后，开发人员会忘记将这些测试商品下架（这种情况在虚拟商品，如购买会员等位置非常常见）。此时如果后端没有对商品id进行校验的话，可能会被攻击者找到这些隐藏的测试商品，进而下单白嫖。

举例说明🌰🌰，以下为一个查询商品的接口

GET /api/goodsinfo?id={id}
Host: example.com

如果这里的平台中存在未下架的测试商品，攻击者就可以用burp抓包遍历goodsid的参数值，然后根据返回包的内容判断是否存在测试商品（一般情况下测试商品的id为0、1等比较靠前的数字，或者商品名会包含“测试”等字样）。若发现有低价的测试商品，就可通过修改前面的 POST /api/createOrder 接口来进行购买。

还有某些特殊商品（如开通会员才可购买等），也可通过此种方式进行绕过限制。

交叉替换支付：

有的平台在支付订单时，可能只会验证该订单号是否存在，而不会校验订单号对应的商品和价格。此时就可能会产生交叉替换支付漏洞。

举例说明🌰🌰，以下为一个生成订单的接口

POST /api/createOrder
Host: example.com

goodsid=1&number=1&price=500

其返回值为

{"succeed":True, "orderid":101}

意为成功生成了一个id为101的订单。

还有一个支付订单的接口

POST /api/payOrder
Host: example.com

orderid=101&amount=500

此时选择两个不同商品，分别产生两个订单支付，并将高价商品的orderid替换为低价商品的orderid值，如果平台没有验证商品相关信息和用户应支付价格，就可以用低价订单的支付价格去买到高价订单的商品。

绕过支付限额：

这类支付漏洞和修改价格类的支付漏洞很像，也比较简单。比如在某些充值入口可能会有“低消”（最低充值金额），如果只在前端指定了金额，并没有在后端再次校验的话，就会存在此类支付漏洞。攻击者就可以利用这种方式绕过“低消”的限制（但此类漏洞很多SRC会认为危害有限😢）。

危害相对大一点的利用是绕过最大金额的限制，因为这样可能会导致商家发不出货，产生法律纠纷。

优惠券类：

此类支付漏洞主要是，由于没有校验订单中的优惠券相关参数，导致在同一订单中使用多个优惠券造成的。

举例说明🌰🌰，以下为一个支付订单的接口

POST /api/payOrder
Host: example.com

orderid=101&amount=500&couponid=11

可以尝试将couponid参数重复多次，比如在couponid=11后面添加&couponid=12&couponid=13来进行此类漏洞的利用。

（个人感觉对优惠券的并发领取也可以算在此类漏洞里面？）

处理方式

上文已经提到，支付漏洞的成因主要是没有对数据本身的正确性进行校验。

那么推荐的漏洞预防/修复方式，包括但不限于：

• 在后端对商品相关的参数进行相互绑定及校验；
• 对相关参数进行加密传输，提高攻击成本；
• 及时下线测试商品；
• 对优惠券、积分等资源加锁；
• …

ps：如果还有其他想法，欢迎评论区交流👀