李 暉, 范立巖, 潘雪松, 馮皓楠

北京郵電大學網(wǎng)絡空間安全學院, 北京 100876

1 引言

隨著計算機、通信和互聯(lián)網(wǎng)等多種技術(shù)的發(fā)展, 第三方支付手段逐漸被人們接受和普遍使用, 以支付寶[1]、Paypal[2]、微信支付[3]和Apple Pay[4]為代表的應用內(nèi)第三方支付蓬勃發(fā)展. 通過在移動終端應用中嵌入第三方支付平臺的SDK, 使得用戶可以在應用內(nèi)直接實現(xiàn)支付賬單功能, 而不需要切換到其他應用或web 瀏覽器, 目前這種支付方式已成為了主流的支付方式[5].

應用內(nèi)第三方支付協(xié)議是用戶、商家和支付方為完成應用內(nèi)支付功能進行的交互協(xié)議, 一般建立在密碼體制基礎上, 其安全性直接關(guān)系到支付能否安全順利地完成[6]. 分析表明, 集成應用內(nèi)第三方支付的App 面臨偽造付款、隱私泄露等威脅[7].特別是Android 平臺因其開放的特性, 以及大量的針對Android平臺的HOOK 框架和易用的攻擊工具, 使基于Android 平臺的支付協(xié)議運行環(huán)境更具風險[8].

目前針對應用內(nèi)第三方支付協(xié)議的安全性分析工作大多依賴經(jīng)驗的直接觀察法、根據(jù)已知的攻擊方法對協(xié)議進行攻擊測試和驗證[5,7]. 截止目前, 尚未發(fā)現(xiàn)采用形式化分析方法來對應用內(nèi)第三方支付協(xié)議進行分析的成果. 而形式化分析方法基于數(shù)學定理和形式推理, 可以更全面的分析協(xié)議的安全性[9,10], 如通過對TLS1.3 協(xié)議[11]的分析, 發(fā)現(xiàn)攻擊者能夠在握手期間成功的模仿客戶端, 通過對5G-AKA 協(xié)議[12–14]分析, 發(fā)現(xiàn)協(xié)議在密鑰保護方面未達到預定的安全目標, 通過對EAP-AKA[15,16]協(xié)議的分析,發(fā)現(xiàn)存在中間人攻擊等.

通過分析發(fā)現(xiàn), 應用內(nèi)第三方支付協(xié)議的形式化分析存在兩個方面的困難:

(1) 應用內(nèi)第三方支付協(xié)議缺乏明確的協(xié)議標準, 研究者難以對協(xié)議流程進行準確地建模. 與很多基于標準化的安全協(xié)議, 如OAuth[17]、5G-AKA[12–14]不同, 目前應用內(nèi)第三方支付的的支付協(xié)議尚未標準化;

(2) 協(xié)議的安全目標模糊, 缺乏可量化的標準. 各個廠商提供的文檔往往只規(guī)定了開發(fā)者需使用API接口和簽名算法, 沒有規(guī)定明確的安全目標.

本文提供了以下貢獻:

(1) 本文選擇了五個在中國使用廣泛的第三方支付平臺[18]: 支付寶、微信支付、銀聯(lián)支付[19]、京東支付[20]和招行一卡通[21], 深入分析這些平臺提供的開發(fā)文檔和樣例代碼, 通過歸納和抽象的方法, 給出了應用內(nèi)第三方支付的協(xié)議流程, 同時提出了協(xié)議的安全假設和安全目標.

(2) 本文對協(xié)議流程和安全目標進行形式化建模, 采用ProVerif 工具對應用內(nèi)第三方支付協(xié)議進行形式化分析, 分析表明在安全假設無法全部滿足的情況下, 存在訂單篡改、訂單替換和通知偽造三種類型的攻擊.

(3) 在對210 個不同類別的App 進行實際攻擊驗證后, 發(fā)現(xiàn)近13.8% 的App 存在被攻擊的隱患.

接下來將在第2 節(jié)描述應用內(nèi)第三方支付協(xié)議的架構(gòu)和流程; 在第3 節(jié)分析協(xié)議的安全假設和安全目標; 在第4 節(jié)對協(xié)議流程、協(xié)議的安全目標進行建模, 并對協(xié)議進行形式化分析; 在第5 節(jié)根據(jù)形式化分析的結(jié)果, 尋找現(xiàn)實中的攻擊實例, 并提出了提高應用內(nèi)支付協(xié)議安全的建議, 最后也就是第6 節(jié), 將給出結(jié)論.

2 應用內(nèi)第三方支付協(xié)議

在從架構(gòu)和協(xié)議流程兩個方面介紹應用內(nèi)第三方支付協(xié)議之前, 為方便閱讀, 表1 列出術(shù)語表.

表1 術(shù)語表Table 1 Term list

2.1 架構(gòu)

如圖1 所示,共有四個實體參與應用內(nèi)第三方支付協(xié)議流程,分別是商家的應用(merchant app,MA)、第三方支付SDK (third-party payment SDK, TP-SDK)、商家服務器(merchant server, MS) 和第三方支付服務器(cashier server, CS). 其中, MA 是安裝在用戶移動終端上的某商家應用客戶端軟件, 用戶通過使用MA 瀏覽、選擇和購買商家的商品; TP-SDK 是集成在MA 中的軟件開發(fā)工具包, 實現(xiàn)了支持應用內(nèi)第三方支付的各種簽名及驗證算法, 并完成在線付款流程; MS 維護存儲與用戶、商品及交易相關(guān)信息的數(shù)據(jù)庫, 并完成與MA 和CS 的交互; CS 記錄支付信息和狀態(tài), 并通知MS 支付完成. MA 不具備抵抗攻擊者攻擊的能力; TP-SDK 具備抵抗攻擊者攻擊的能力; MS 和CS 具有較強的實體安全性. MA 和MS、TP-SDK 和CS 通過無線方式進行交互, 存在被攻擊的隱患; MA 和TP-SDK 通過進程間通信進行交互, 同樣存在被攻擊的隱患, MS 和CS 通過服務器間的數(shù)據(jù)專線進行交互, 安全性較高.

圖1 應用內(nèi)第三方支付架構(gòu)圖Figure 1 Architecture of in-app third-party payment

2.2 協(xié)議流程

在用戶使用應用內(nèi)第三方支付協(xié)議之前, 用戶需要完成新用戶注冊及綁定第三方支付賬號的相關(guān)流程, 從而使得用戶具有在MA 中購買并支付商品的能力. 隨后, 用戶在下訂單后啟動第三方支付協(xié)議流程.

應用內(nèi)第三方支付協(xié)議可分為四個階段: (1) 生成訂單; (2) 綁定訂單; (3) 在線付款; (4) 通知結(jié)果.如圖2 所示.

(1) 生成訂單: MA 向MS 提交訂單申請(order information, odi), 包含商品名和商品數(shù)量信息.

(2) 綁定訂單: MS 收到訂單申請后, 進入綁定訂單流程, 微信支付、銀聯(lián)支付和京東支付需要完成可選流程(圖2 中用虛線框表示), 而支付寶和招行一卡通則無需執(zhí)行可選流程. 在可選流程中,MS 采用自己的私鑰對tri 進行簽名后傳至CS; CS 驗簽并校驗后, 生成支付流水號(prepay id number, pidn) 和隨機數(shù)(nonce number,n), 之后再對上述信息進行簽名后傳給MS. MS 收到可選流程中傳過來的信息, 先驗簽, 再將pidn 和n合并成tri, 重新簽名后傳給MA. 不執(zhí)行可選流程的協(xié)議在MS 收到訂單后直接確認MA 提交的新訂單申請, 生成訂單號(trade number, tn)以及訂單詳細信息(transaction information, tri), MS 采用自己的私鑰生成對tri 的簽名S后,將tri 和S傳給MA. MA 對收到的信息進行簽名驗證后, 向用戶展示交易詳細信息, 并將tri 和簽名S傳至TP-SDK.

圖2 支付流程Figure 2 Diagram of payment

(3) 在線付款: TP-SDK 收到信息后, 先進行tri 信息校驗, 成功后, TP-SDK 調(diào)應用內(nèi)第三方支付收銀臺功能, 由用戶輸入支付密碼(pay pass-word, ppw), 完成付款.

(4) 通知結(jié)果: 付款成功后, CS 分別使用同步通知和異步通知兩種方式通知付款結(jié)果. 其中同步通知流程為: CS 向TP-SDK 返回由自己私鑰簽名后的付款詳細結(jié)果(result information, ri). TPSDK 將消息傳至MA. MA 向用戶展示ri 后, 再將ri 傳至MS, MS 進行簽名驗證、解析ri 且核對正確后, 同步通知結(jié)束; 而異步通知流程為: CS 向MS 返回由自己私鑰簽名后的ri, MS 進行簽名驗證、解析ri 且核對正確后, MS 完全校驗ri, 本次交易完成.

3 安全假設與安全目標

在對第三方支付平臺提供的開發(fā)文檔進行充分分析后, 本節(jié)將描述確定的威脅模型和明確的安全目標, 這些都是采用形式化方法分析安全協(xié)議的前提和關(guān)鍵要素.

3.1 安全假設和威脅模型

參考微信支付給出的最佳安全實現(xiàn)范例[22], 本文從密碼算法、信道、數(shù)據(jù)保護和參與實體四個方面描述安全假設.

密碼算法假設: 在應用內(nèi)第三方支付協(xié)議采用的密碼算法, 僅包括簽名算法, 假設攻擊者在不知道正確密鑰的情況下, 無法偽造簽名或者解密消息.

信道假設: 協(xié)議運行時的信道分成兩類: (1) 公開信道: 攻擊者可以在其中竊聽, 攔截, 刪除, 修改并且傳輸消息. (2) 私有信道: 攻擊者無法將消息發(fā)送到此信道的任何參與實體, 也無法在該信道上竊聽或者修改消息. 由于MA 和MS 之間的通訊沒有采取任何保護措施, 因此, 假設其信道為公開信道; 而MS 和CS 通過數(shù)據(jù)專線交互, TP-SDK 和MA 的通信采用了進程間通信的方式通訊, 由操作系統(tǒng)保證通信安全性, TP-SDK 和CS 之間通訊的安全性由第三方支付平臺采用HTTPS 協(xié)議或私有協(xié)議、服務器防刷和SO 加密等技術(shù)來保證, 因此, 假設MA 和MS、MS 和CS、TP-SDK 和CS 的通信信道為私有信道.

數(shù)據(jù)保護假設: 假設簽名公鑰是公開的, 而簽名私鑰是用戶自己保存的秘密密鑰, 不能被泄露.

參與實體假設: 下面通過分析實體可能被實際攻擊的情況給出實體假設. 首先, TP-SDK 具備抵抗攻擊者攻擊的能力, 攻擊者不能通過攻擊實體獲取信息或?qū)嵤┘倜肮? 其次, MA 不具備抵抗攻擊者攻擊的能力, 實體被攻擊后, 攻擊者可以獲得MA 的源碼和數(shù)據(jù), 并可以對MA 進行動態(tài)調(diào)試. 這種假設是合理的, 因為第三方支付廠商被要求采用安全加固和代碼混淆等技術(shù)手段對TP-SDK (內(nèi)有關(guān)鍵安全算法)進行保護, 但不強制對MA 做與TP-SDK 同等能力的安全防護. 最后, 本文主要研究來自移動終端的可能攻擊, 因此, 假設MS 和CS 是具有實體安全性, 即攻擊者不能獲得MS 和CS 存儲的數(shù)據(jù).

綜合上述各種假設, 考慮到協(xié)議尚未標準化、開發(fā)者開發(fā)MA/MS 時存在對協(xié)議的簡化、Android 平臺中存在的密碼學誤用[23]等現(xiàn)實情況, 為了使分析結(jié)果可以覆蓋更廣的場景和便于分析, 本文將按照下面5 種不同的安全假設條件分別對協(xié)議進行建模和分析:

安全假設1: 假設參與實體(MA、TP-SDK、MS 和CS) 完整地實現(xiàn)了協(xié)議, MA 和MS 之間使用了安全的通信協(xié)議, TP-SDK 具備抵抗攻擊者攻擊的能力, MA 不具備抵抗攻擊者攻擊的能力;

安全假設2: 簽名私鑰被寫入MA, 且MS 未完全校驗ri;

安全假設3: 在安全假設2 的基礎上, tn 和tri 由MA 生成且未經(jīng)MS 簽名;

安全假設4: MA 和MS 之間未使用安全通信協(xié)議(如HTTPS 協(xié)議), 且MA 未完整展示支付信息;

安全假設5: MS 省略了驗簽過程, 且MS 未完全校驗ri.

3.2 安全目標

本文從機密性、認證性、完整性和不可否認性四個方面, 給出應用內(nèi)第三方支付協(xié)議安全目標的形式化表述.

機密性:任何情況下, 簽名私鑰SKMS 和SKCS 都應該保持機密, 否則, 消息簽名機制將失去作用.形式化地:

認證性:應用內(nèi)第三方支付協(xié)議應滿足參與實體的認證性.例如, MA 向MS 發(fā)起新訂單申請odi, MS接受odi 并將生成的tn 和tri 簽名并返回給MA, MA 接收后驗證MS 簽名, 這個過程可以看作是MA和MS 的相互認證. 這里采用了Lowe 的認證屬性分類法[24], 將實體A 和B 之間的認證屬性由弱到強分為四種: 弱一致性(weak agreement)—只確保B 在之前已經(jīng)運行過協(xié)議但不一定跟A 一起運行; 存活性(aliveness)—確保B 曾與A 一起運行協(xié)議但不一定使用相同的數(shù)據(jù); 非單射一致性(no-injective agreement)—確保B 與A 一起運行協(xié)議, 并對數(shù)據(jù)達成一致; 單射一致性(injective agreement)—在非單射一致性的基礎上保證B 的每次運行對應A 的唯一運行. 該分類法廣泛應用于協(xié)議的形式化研究[12].形式化地:

完整性:任何情況下, 訂單信息應保持完整, 否則, 攻擊者可能會篡改訂單申請和訂單信息.具體地: 在存在攻擊者的情況下, odi 應在生成訂單階段保持完整, tn 應在綁定訂單階段保持完整, tri 應在綁定訂單階段保持完整. 形式化地:

不可否認性: 在任何情況下, 協(xié)議結(jié)束時能夠分別給MA 和MS 提供有效的對方不可否認證據(jù). 應用內(nèi)第三方支付協(xié)議應保證odi, tri, tn 和ri 的不可否認性. 形式化地:

4 形式化分析建模

4.1 建模工具

本文使用ProVerif 工具進行形式化分析. ProVerif 是一種自動的符號協(xié)議驗證工具, 可以驗證協(xié)議的機密性、認證性等安全屬性[25], 廣泛應用于分析包括TLS1.3 協(xié)議在內(nèi)的諸多安全協(xié)議[26–28]. 與其他形式化分析工具相比, 如AVISPA[29]和Tamarin[30], ProVerif 解決了狀態(tài)爆炸的問題, 且支持無限次數(shù)的會話. ProVerif 使用應用pi 演算進行驗證, 并基于Horn 子句[31]的一階邏輯解析規(guī)則. ProVerif 首先驗證協(xié)議是否滿足安全目標, 如果不滿足安全目標, 則嘗試自動構(gòu)造攻擊.

4.2 安全目標建模

對于機密性, attacker 語句可以直接質(zhì)詢攻擊者是否可以獲得機密. 例如, 質(zhì)詢攻擊者是否可以獲得MS 的簽名私鑰:

對于認證性, 首先定義與身份認證相關(guān)的事件類型, 然后質(zhì)詢事件之間是否存在對應關(guān)系. 例如, 事件CreatOrderInfo(odi)表示MA 發(fā)出了odi, 事件MS_Generate_OutTradeNo(odi)表示MS 根據(jù)odi 生成了訂單號. 然后用以下方式質(zhì)詢這兩個事件是否存在關(guān)于odi 的單射一致性對應關(guān)系:

對于完整性, ProVerif 沒有提供直接驗證完整性的語句, 但可以通過間接方式質(zhì)詢. 例如, 事件MS_Generate_Transaction(odi, tn, tri) 表示MS 根據(jù)odi 和tn 生成了tri, MS_ALL_SUCCESS_Asyn(tn, tri) 表示MS 相信訂單號為tn, 交易信息為tri 的這筆交易已經(jīng)成功了. 然后質(zhì)詢這兩個事件是否存在非單射一致性的對應關(guān)系. 如果存在, 則證明在tn 和tri 未被篡改. 例如:

對于不可否認性, 在應用內(nèi)支付的四個階段中, 定義與不可否認性相關(guān)的事件類型. 例如, 在生成訂單階段, 事件CreatOrderInfo_Fin(odi) 表示MA 已經(jīng)向MS 發(fā)出了odi, 事件MS_Generate_OutTradeNo_Fin(odi) 表示 MS 收到了 MA 發(fā)出的 odi 且已經(jīng)生成了訂單號. 然后, 在 MA 發(fā)出訂單后中注冊事件CreatOrderInfo_Fin(odi), 在MS 接收訂單申請并生成訂單號過程后注冊事件MS_Generate_OutTradeNo_Fin(odi). 在最后質(zhì)詢這兩個事件在生成訂單階段結(jié)束后是否均已發(fā)生:

4.3 協(xié)議流程建模

參與協(xié)議的四個實體被建模成四個宏, 每個宏由描述協(xié)議流程的語句組成. 例如, let MA(odi: bitstring) 表示實體MA 的宏, 參數(shù)odi 表示MA 的訂單申請, out(HTTPS-Msg1, Msg1) 表示MA 向HTTPS-Msg1 信道發(fā)送Msg1, in(HTTPS-Msg1, Msg2-A1: bitstring) 表示MA 從HTTPS-Msg2-A1信道接收Msg2-A1:

為了更準確的對信道進行建模, 提升Proverif 的分析效率, 實體間的信道建被模成多條邏輯子信道.例如, MA 和MS 之間的通信了三次, 則建模三條邏輯子信道, 信道HTTPS-Msg1 傳輸消息Msg1, 信道HTTPS-Msg2-A1 傳輸消息Msg2-A1, 以此類推:

5 安全分析

在這部分將首先給出在五種安全假設條件下的應用內(nèi)第三方支付協(xié)議的形式化分析結(jié)果, 之后給出了通過形式化分析找到的可能的攻擊流程, 最后給出了對采用第三方支付協(xié)議的App 進行攻擊測試的結(jié)果.

5.1 形式化分析結(jié)果

表2 為機密性和認證性的分析結(jié)果, 表3 為完整性和不可否認性的分析結(jié)果,表示滿足安全目標, ×表示不滿足安全目標, ! 表示部分滿足安全目標. 可以看出, 除了在安全假設1 的條件下, 應用內(nèi)第三方支付協(xié)議都存在安全目標無法全部滿足的情況.

表2 機密性和認證性分析結(jié)果Table 2 Analysis result of confidentiality and authentication

表3 完整性和不可否認性分析結(jié)果Table 3 Analysis result of integrity and non-repudiation

ProVerif 構(gòu)造了三種潛在類型的攻擊: (1) 訂單篡改攻擊. (2) 訂單替換攻擊. (3) 通知偽造攻擊. 在安全假設2 或安全假設3 下, 協(xié)議將遭受訂單篡改攻擊; 在安全假設4 下, 協(xié)議將遭受訂單替換攻擊; 在安全假設5 下, 協(xié)議將遭受通知偽造攻擊.

5.2 可能的攻擊

訂單篡改攻擊: 在安全假設2 或安全假設3 下, 安全目標C1、I2、I3 和NR2 未能達到. 對于A1-A4,協(xié)議沒有達到單射一致性的認證性, 只能部分達到非單射一致性的認證性. 在上述安全目標未能達到時,存在一種潛在的訂單篡改類型的攻擊. 在這種類型的攻擊中, 攻擊者充當惡意用戶, MS 為受害者. 在這種情況下, 攻擊者會篡改tri, 并重新簽名, 或者在本地生成訂單的情況下, 直接篡改tri, 并重新簽名. 最終,在商家不知情的情況下, 攻擊者可以支付更少的錢. 圖3 和圖4 分別為兩種訂單篡改攻擊的示意圖.

圖3 訂單篡改攻擊1Figure 3 Order tampering attack 1

圖4 訂單篡改攻擊2Figure 4 Order tampering attack 2

訂單替換攻擊: 在安全假設4 下, 安全目標NR1、P2、A1、A2、A4、I1、I2 和I3 未能達到. 在這種情況下, 存在一種中間人攻擊. 在這種類型的攻擊中, 攻擊者充當中間人, MA 為受害者. 在這種攻擊中,攻擊者將一筆交易的訂單替換為另一筆交易, 并誤導受害MA 在不知不覺中為攻擊者的訂單付款. 當MA和MS 的消息是通過不安全的網(wǎng)絡通信通道傳輸時, 攻擊者可以截取消息, 并用另一筆合法交易替代, 并將其發(fā)送給MA. 然后, 受害者將為攻擊者的訂單付費. 圖5 為訂單替換攻擊的示意圖.

圖5 訂單替換攻擊Figure 5 Order replacement attack

通知偽造攻擊: 在安全假設5 下, 安全目標NR3、A3 和A4 未能達到. 在這種情況下, 存在一種通知偽造攻擊.在這種類型的攻擊中, 攻擊者充當惡意用戶, MS 為受害者.攻擊者在TP-SDK 要求用戶確認訂單并輸入密碼時不付款, 并向MS 發(fā)送偽造的付款結(jié)果通知. 最終, 攻擊者可以不付錢并得到商品. 圖6 為通知偽造攻擊過程示意圖.

圖6 通知偽造攻擊Figure 6 Notification forgery attack

5.3 攻擊驗證結(jié)果

本文從騰訊應用寶批量下載了近300 個App, 涵蓋了下載量榜單的頭部中部和尾部. 經(jīng)篩選, 共有210 個App 集成了應用內(nèi)第三方支付. 經(jīng)驗證, 13.8% 的App 存在形式化分析結(jié)果中發(fā)現(xiàn)的安全隱患, 這些App 主要分布在下載量榜單的尾部. 共計4 個App 面臨訂單篡改的風險, 22 個App 面臨訂單替換的風險, 3 個App 存在通知偽造的風險. 表4 為App 檢測結(jié)果匯總.

表4 App 檢測結(jié)果Table 4 Result of app test

涉及網(wǎng)絡通信的部分, 通過burp suite 等工具搭建代理網(wǎng)絡進行實驗. 近33.8% 的App 在進行應用內(nèi)第三方支付時使用HTTP 通信, 這意味著在生成訂單、綁定訂單到和通知付款結(jié)果這三個階段, 攻擊者可以輕而易舉的獲得交易的詳細信息. 4% 的MS/MA 省略了驗簽過程; 1.43% 的MS 消息未簽名.4.76% 的App 存在MS 未完全校驗ri 的情況.

對于tn 和tri 由MA 生成、將簽名私鑰等放進MA 這兩種情況, 在使用Apktool 和IDA 對App逆向分析后, 發(fā)現(xiàn)部分App 存在本地生成tn 和tri 的代碼, 結(jié)合網(wǎng)絡流量分析, 這些App 在訂單生成以及綁定訂單到支付階段, 或未與MS 進行交互, 或?qū)⒈镜厣傻膖n 和tri 發(fā)給MS, MS 簽名后發(fā)回MA.約13.8% 的App 存在本地生成tn 和tri 的情況. 在靜態(tài)分析的過程中, 發(fā)現(xiàn)2.38% 的App 存在將簽名私鑰寫入MA 的情況.

對于MA 未完整展示支付信息, 則對App 逐個進行人工分析, 檢測支付時App 是否將支付信息完整的展示給用戶. 經(jīng)檢測, 36.2% 的App 存在支付信息展示不全的情況, 這些App 只展示了交易的總金額,不展示訂單號, 商品名和商品數(shù)量等信息. 表5 為上述缺陷在樣本App 中的命中率.

表5 缺陷命中率Table 5 Defect hit rate

需要指出的是, 不同于傳統(tǒng)的購物App, 很多工具類、教育類、文娛類和單機游戲類的App 常常使用應用內(nèi)第三方支付完成付費解鎖某項功能, 可付款的內(nèi)容一般被在App 代碼中進行限制, 而不是從服務器獲取, 這些App 更易于被攻擊.

5.4 建議

本文的工作表明, 應用內(nèi)第三方支付協(xié)議在Android 平臺進行實現(xiàn)的過程中, 存在多種無法保證應用內(nèi)第三方支付的安全性的實現(xiàn)實例. 為了盡可能地規(guī)避這種情況, 本文給出了如下建議.

對于第三方支付平臺:

(1) 應用內(nèi)第三方支付協(xié)議應標準化. 目前, 大部分第三方支付平臺只提供協(xié)議的簡易流程圖和API接口說明, 缺乏對協(xié)議的規(guī)范化描述, 且說明內(nèi)容分散在各個文檔中, 導致開發(fā)者難以準確地理解協(xié)議, 缺乏對協(xié)議的總體認識, 更多是在“面向API 接口” 開發(fā).

(2) 明確應用內(nèi)第三方支付協(xié)議的安全目標. 相比于FIDO 協(xié)議、Oauth 協(xié)議和5G-AKA 協(xié)議中明確的安全目標, 除微信支付對關(guān)于機密性的安全目標稍有提及外, 其他的第三方支付平臺幾乎沒有對協(xié)議提出安全目標. 安全目標不是默認的、總所周知的, 而應由平臺明確提出并規(guī)范化, 并涵蓋機密性、完整性、認證性和不可否認性等安全屬性.

對于應用:

(1) 需要實現(xiàn)MA 與MS 之間安全的網(wǎng)絡通信, 例如使用HTTPS 協(xié)議并正確配置SSL 證書.

(2) 需能保證MA 可以展示支付的詳細信息, 包括本次支付的總金額, 支付的商品名和商品數(shù)量, 訂單號等.

(3) 需要確保MA 和MS 的簽名& 驗簽過程不能被省略, 證書配置正確.

(4) 需要保證訂單號& 訂單詳細信息在MA 提交訂單申請后由服務器生成, 而不是由MA 本地生成.

(5) 需要保證MS 能夠完成同步通知和異步通知, 并完成核對通知結(jié)果.

6 結(jié)束語

本文通過對應用內(nèi)第三方支付協(xié)議進行形式化分析及對Android 系統(tǒng)App 進行實際攻擊驗證, 表明各種各樣的原因使得應用內(nèi)第三方支付協(xié)議常常運行在缺陷狀態(tài)下, 導致協(xié)議無法達到其安全目標. 這些原因包括官方文檔對安全目標的描述缺失、對協(xié)議流程的非標準化描述等使得開發(fā)人員更容易對協(xié)議的理解錯誤和簡化開發(fā), 最終使應用內(nèi)第三方支付協(xié)議易于遭受攻擊. 最后, 為保證應用內(nèi)第三方支付協(xié)議的安全性, 本文對第三方支付平臺和應用的開發(fā)者給出了建議. 在未來的工作中, 將重點從擴充安全假設、細化安全目標、擴大App 攻擊測試范圍這三個維度繼續(xù)深入研究.