支付接口安全测试记录

0x1. 低价值替换高价值SKU

在IOS平台上面支付完成之后，立刻杀掉进程，然后重新开启APP抓包，此时触发补单操作，拦截包之后，修改sku字段为高价值商品，尝试是否可以成功。

或者在Burp抓支付包的时候，因为apple服务接口验证了证书，可以在burp的TLS Pass Through配置绕过apple的域名，不对其进行抓包。

0x2. 替换订单号

首先产生一个未支付的高价值的订单号，其次正常购买低价值商品，打断后端返回的response，替换response里面的订单号为高价值订单号，然后尝试支付成功之后商品的数量。一般适用于Google支付。

0x3. 利用Google机制自动退款

Google的SDK支付成功之后，客户端会发起一个接口请求: https://play-fe.googleapis.com/fdfe/consumePurchase

Google Play结算服务官方文档中关于处理购买交易的描述：在三天内未确认购买交易，则用户会自动收到退款，并且Google Play会撤消该购买交易，可以利用此规则进行退款。这种攻击一般针对一次性消耗品，当然重复的也可以。在支付完成之后，拦截上面的请求之后丢弃，如果服务端未做正确处理，则三天之后Google会自动退款。

修复方式：后端手动调用确认接口进行二次确认acknowledge，一般400可以视为已确认，409的时候需要查询一次状态，已确认状态可以放行，否则掉单处理。

0x4. IOS跨应用票据伪造

在IOS支付的时候，Apple有一个responsebody，服务端需要对其中的bundle_id做一次验证，不然出现跨应用攻击。原理是B应用创建一个和A应用SKU一样的产品，标记一个极低的价格，一半是0.99，然后在B应用内支付之后使用支付之后Apple产生的票据去A应用走票据验证流程，具体场景如下：

攻击者A自己注册了IOS开发者账号，在Apple后台配置了B应用在支付的时候的ProductID，比如awpod.tthgb.asx17。此时A在自己开发的应用中发起支付，抓取Apple返回的支付之后票据，正常的下一步是把票据发给Apple服务端。但是攻击者会把这票据截下来发给B应用的验证接口，请求里面带上B的最高金额产品ProductID，如果B应用服务端没有验证bundle_id字段，此时跨应用攻击就会生效，B应用一分钱没拿到。

上面四种场景是几千万RMB血淋淋教训

测试注意点

  • 某些版本的Burp抓不到Google的消费请求，或者是Burp显示DF-DFERH-01错误，这时候多更换burp版本试试，比如社区版
  • 熟练利用Burp的TLS Pass Through和Intercept Client Requests功能抓包。
⬆︎TOP