TYPESDK手游聚合SDK服務(wù)端設(shè)計思路與架構(gòu)之四：流程優(yōu)化之信息安全與訂單校驗

有了前文幾個步驟的分析和設(shè)計，TYPESDK的信息交互流程已經(jīng)可以正常工作了，但是，這個流程還沒有考慮到支付這樣的過程中，至關(guān)重要的信息安全問題。

在整個交互過程中，游戲服務(wù)端，SDK服務(wù)端，渠道服務(wù)端都屬于安全區(qū)域，這部分發(fā)生的數(shù)據(jù)交互，基本是可以信任的，只需要作相對簡單的處理工作；而客戶端，包括游戲客戶端，SDK客戶端都屬于危險區(qū)域，在這部分產(chǎn)生的數(shù)據(jù)和請求，都有可能受到外部的攔截和篡改。因此，我們需要在流程上加以預(yù)防和控制。

圖1

從示意圖1可以看出。針對三類不同安全性的數(shù)據(jù)流，我們的處理原則也是不同的。

l  藍色箭頭所表示的是安全可信的請求。屬于這類請求的是游戲服務(wù)端與SDK服務(wù)端之間通信的請求。對這類請求傳送的信息，原則上可以直接予以信任，并且以之作為基礎(chǔ)，完成流程和邏輯的控制。在TYPESDK的設(shè)計中，對這部分請求，設(shè)置的安全機制是簡單的通信key簽名校驗。

l  綠色箭頭所表示的是半可信的請求。具體來說包括渠道服務(wù)端與SDK服務(wù)端之間的通信請求。由于渠道服務(wù)端處于開發(fā)者可知范圍之外，雖然絕大多數(shù)情況下該地址是可靠的，但是在將交互信息用于邏輯之前，需要做安全校驗。通常采取的措施有：

n  數(shù)據(jù)摘要簽名/請求串加密。這部分處理通常在渠道服務(wù)端文檔內(nèi)會寫明處理邏輯及校驗算法。

n  訪問IP白名單控制。在SDK服務(wù)器上配置指定渠道IP白名單，只信任來自白名單內(nèi)IP的請求。同樣，部分渠道也會通過后臺配置或技術(shù)人員聯(lián)系的形式設(shè)置開發(fā)者的服務(wù)器IP為白名單。

l  紅色箭頭表示的是不可信的請求?；旧希c客戶端通信的所有請求都是不可信的請求。由于各請求隸屬的模塊不同，處理方式也各有分別?；旧嫌幸韵聨追N：

n  渠道客戶端庫與渠道服務(wù)端之間的通信，這部分數(shù)據(jù)交互由渠道本身機制來保證其可靠性，采用的技術(shù)手段包括token驗證，客戶端加密，簽名身份識別等等機制。對于開發(fā)者而言，可以簡單的認為，從渠道提供的接口獲得的數(shù)據(jù)是可信的，提交給渠道的信息也不用作多余的安全處理機制，否則可能會產(chǎn)生其他問題。

n  游戲客戶端與服務(wù)端之間的通信，相信已經(jīng)有很多專述文章說明。常見的安全檢測機制包括token，時間戳，簽名等校驗方式。但是專注于安全的渠道庫并非專注游戲性的游戲客戶端可比。出現(xiàn)破解或者請求被攔截的情況可謂司空見慣。因此，在游戲邏輯架構(gòu)設(shè)計的階段就要將安全性要求考慮在內(nèi)。遵循以下原則：

1.         原則上重要邏輯必須使用服務(wù)端計算，客戶端只負責(zé)展示和效果。例如前一篇文字里提到過的創(chuàng)建訂單邏輯，由服務(wù)端產(chǎn)生訂單?？蛻舳丝梢越邮沼唵翁柸缓笳故窘o用戶，以及傳送給渠道客戶端。

2.         原則上所有數(shù)據(jù)信息都以服務(wù)端保留的記錄為準，客戶端提供的記錄或者數(shù)據(jù)只作為參考比對。有沖突時服從服務(wù)端。例如，用戶破解了客戶端并且篡改了客戶端傳輸給渠道客戶端的內(nèi)部訂單號。在后續(xù)的發(fā)貨及對賬時，游戲服務(wù)端只信任服務(wù)端自己保持的訂單狀態(tài)，對不符合的訂單直接拋棄或留記錄不處理。

n  SDK客戶端與服務(wù)端之間的通信，這部分數(shù)據(jù)交互并不多，通常適用于一些token轉(zhuǎn)發(fā)，換簽之類的特殊渠道邏輯，后文會有詳細說明。SDK服務(wù)端對這些不安全數(shù)據(jù)的處理方式是保留記錄以資比對，但不作為任何邏輯的根基和依據(jù)。

根據(jù)以上原則，我們分析了各類數(shù)據(jù)交互的安全性特點以及處理原則，很容易就會發(fā)現(xiàn)，在我們原本的支付-發(fā)貨邏輯中，缺失了重要的一環(huán)，即訂單校驗步驟。沒有這一步驟，SDK服務(wù)端在收到渠道的發(fā)貨回調(diào)后，會立刻通知游戲服務(wù)端處理發(fā)貨邏輯。然而根據(jù)以上的分析，渠道支付訂單的提交步驟事實上是在不安全區(qū)域-客戶端內(nèi)完成的，這一步驟可以被別有用心的用戶攔截并修改。舉例如下：

例1：用戶點擊游戲中的大禮包購買，生成了一筆金額為648元的訂單，然后使用非法工具在渠道客戶端提交訂單時，攔截該訂單，并修改其金額為0.01元，隨即完成支付。渠道異步回調(diào)給SDK服務(wù)端時，SDK服務(wù)端判定其為合法訂單并通知游戲服務(wù)端發(fā)貨。結(jié)果是用戶成功獲取了非法利益648元。

例2：用戶通過非法工具，獲取并保存了自己一筆正常訂單648元的所有訂單信息。隨后通過技術(shù)手段，將該訂單的回調(diào)信息重發(fā)給了SDK服務(wù)端。該訂單一切信息都與前一筆正常支付相同，SDK服務(wù)端判定其為合法訂單并通知游戲服務(wù)端發(fā)貨。結(jié)果是用戶又成功獲取了非法利益648元。

如何避免例子中的情形發(fā)生？比較簡單的手段是在游戲服務(wù)端進行訂單比對和信息校驗，但是這樣的處理不可避免的要和具體渠道的訂單字段和處理邏輯掛鉤，例如，渠道A的回調(diào)信息中含有訂單金額字段，可以用于比對，而渠道B的回調(diào)信息中只有單價和數(shù)量字段，如需比對只能自己計算總金額。又例如，渠道C會定期做優(yōu)惠活動，充值折扣打9折，返回的充值金額也是9折后的數(shù)值，和原本游戲訂單中的金額不一致。這些邏輯不可能都讓游戲服務(wù)端來處理，否則，就失去了聚合SDK的意義。因此，我們需要讓游戲服務(wù)端提供一個訂單查詢verify接口，每當SDK服務(wù)端接收到渠道的回調(diào)請求時，調(diào)用該接口，進行訂單比對，只有比對通過時，才會通知游戲服務(wù)端發(fā)貨，這樣就比較圓滿的解決了這種情形。

但是，SDK服務(wù)端并不能解決所有問題，游戲服務(wù)端還是需要把好最后一道關(guān)。例如合法訂單的重復(fù)發(fā)送邏輯，就需要游戲服務(wù)端處理好，接收到重復(fù)的訂單號時，不要重復(fù)發(fā)貨。

修改后的發(fā)貨邏輯如下圖所示：

圖2

流程說明

1.       充值訂單到帳后，渠道服務(wù)端異步通知TYPESDK服務(wù)端

2.       TYPESDK服務(wù)端通過訂單中的內(nèi)部訂單號，查詢充值信息提交接口提交的訂單信息，獲取游戲訂單查詢URL，向該URL發(fā)起請求獲取游戲服務(wù)端保存的訂單信息，用于對比判定該訂單是否合法。

3.       游戲服務(wù)端通過提交的內(nèi)部訂單號查詢訂單信息，返回給TYPESDK服務(wù)端

4.       TYPE服務(wù)端校驗通過，通知游戲服務(wù)端發(fā)貨

5.       游戲服務(wù)端收到發(fā)貨請求后先保存該請求，立刻返回TYPESDK服務(wù)端，表示已收到發(fā)貨請求。將該訂單的狀態(tài)置為已付款未發(fā)貨。

l  不要處理完發(fā)貨請求之后再返回，可能造成渠道通知請求超時，導(dǎo)致該通知重復(fù)發(fā)送

l  注意渠道為保證通知到達，可能會重復(fù)發(fā)送發(fā)貨請求，TYPESDK會原樣轉(zhuǎn)發(fā)所有請求。游戲服務(wù)端需要做防止同一訂單號重復(fù)發(fā)貨的處理。

6.       TYPESDK返回渠道服務(wù)端

7.       游戲服務(wù)端異步處理發(fā)貨邏輯，將該訂單的狀態(tài)置為已發(fā)貨。并通知游戲客戶端

這個項目已開源，大家有興趣可以自己研究或者參照項目編寫自己的聚合SDK

項目地址：https://code.csdn.net/typesdk_code

項目地址：https://github.com/typesdk