支付框架常见攻击面

最新推荐文章于 2024-03-31 16:19:54 发布

yeshen4328

最新推荐文章于 2024-03-31 16:19:54 发布

阅读量510

点赞数

分类专栏：支付安全

原文链接：https://www.researchgate.net/publication/316913275_Show_Me_the_Money_Finding_Flawed_Implementations_of_Third-party_In-app_Payment_in_Android_Apps

版权

安全同时被 2 个专栏收录

7 篇文章 0 订阅

订阅专栏

支付

1 篇文章 0 订阅

订阅专栏

支付框架业务流程以及常见攻击面

主流支付框架

目前主流的支付应用有支付宝、微信支付、银联和百度支付，众多应用都集成了它们一种或者多种支付功能。在整个支付流程中包含一下几个部分（可能不同版本有些不同）：支付应用服务器（cashier server，cs）、电商应用（merchant app，MA），电商应用服务器（merchant server，MS），以及支付应用SDK（TP-SDK）。

模型1:微信和银联

下面这个支付流程是微信和银联采用的流程，在具体实现过程可能会有不同，但是总体是相似的；
在这里插入图片描述

模型2:支付宝和百度支付

在这里插入图片描述

攻击模式

在讲解攻击面之前，我们需要确定攻击者能够控制什么。我们假设攻击者是一个普通的用户（恶意用户），他能够掌握自己手机上支付应用以及集成支付功能的应用上面的数据，同时攻击者还能捕获和控制到支付应用和电商应用和服务器之间的通信数据，包括破坏、伪造报文（手机是攻击者的），攻击者不能控制电商服务器和支付服务器之间的通信数据。

安全规则

基于上述两种支付流程的观察，为了实现安全的支付功能，开发者需要履行一些安全规则；

支付订单（order_p）必须由电商服务器（MS）生成并发送；
在电商应用（MA）上不能存储任何敏感信息（签名的密钥）；
SDK需要通知用户支付订单的具体信息；
SDK需要校验所有的来自MA的交易信息；
客服端应用到各个服务器之间的通信要加密；
各方需要校验所有接受到的数据的签名；
电商服务器需要向支付服务器确刚完成的认支付信息；

其实上述的安全规则就是对支付框架做渗透测试的测试点；

订单篡改

如果规则1、7被打破，也就是说支付订单是从MA上发起的，且MS在支付完成之后没有没有向支付服务器确认支付信息。

在这种情况下，攻击者可以修改MA上支付订单的信息，例如商品数目和单价等，以达到用较少的钱买更多的商品。

对于模型1，正常情况下，支付订单（order_p）由电商服务器发起，手机应用只能收到TN（签名过的交易数），它不包含任何支付相关的信息，因此攻击者无法从MA发起攻击。如果开发者在MA上发送支付请求，那么攻击者就能控制自己手机上的MA发送伪造支付订单给CS，攻击流程如下图所示：
在这里插入图片描述
对于模型2，正常情况下MS会将支付订单返回给MA，并发给SDK，由于order_p是MS签名过的，攻击者无法修改支付订单（CS会校验签名）。如果MS把签名密钥硬编码（或者误将密钥发送给MA）在MA上获取开发者压根没签名，那么攻击者就能在MA上对支付订单进行修改，并把伪造的支付信息发送给SDK。要实现该攻击，在支付完成之后，MS没有向CS核对支付信息；攻击流程如下：

在这里插入图片描述

通知伪造

如果规则2，7被打破，那么攻击者就可能伪造CS给MS发送支付完成的消息，攻击者可以不支付就能获取到商品；

在支付流程中，当用户在手机端提交订单并进入支付界面时，用户在输入密码并点击确认之前，是还没有付款的，只有用户点击确认之后，SDK才会给CS发送请求，且CS会发送支付完成的通知给MS，这时候MS就确认了订单并准备发货。如果攻击者能够伪造CS给MS发送支付完成的通知，那么攻击者就能不花钱买到商品，这需要规则2，7被打破才能实现。

正常情况下，CS发送给MS的消息都是经过签名的，攻击者修改之后MS在做校签时就会拒绝该请求。如果开发者误将签名用的密钥放在MA上或者SDK上了，那么攻击者可利用改密钥伪造签名，攻击方式如下图所示。

签名的方式一般有sha1-rsa签名和hash函数签名。有些支付框架采用对称密钥做hash来进行签名已经校验发送者的身份，如果MS的开发者泄漏了密钥，攻击者就有可能获取到密钥伪造支付完成的通知。采用rsa签名方式相比之下安全更多，应该保存在CS上的密钥不太可能泄漏。

模型1攻击：
在这里插入图片描述
模型2攻击：

订单替换

如果CS的SDK没有显示地提示用户支付订单详情以及SDK没有校验来自MA的消息（不遵守规则3，4）、MS和MA通信信道不安全，可被中间人攻击（不遵守规则5），那么可能导致普通用户的订单被攻击者替换成其他订单，这样造成用户为别人的订单花钱。攻击方式如下：
在这里插入图片描述
上述模型2的攻击方式表明，MS发送给MA的order_p被攻击者截获并替换成其他的订单。在模型1中，被替换的就是TN。
订单替换问题的本质是MS和MA之间的信道不安全或者说攻击者找到某种方式绕过了安全机制（签名校验、证书校验等），同时SDK的订单显示信息不够全，导致普通用户的订单被替换而没有发觉；