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

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

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

圖1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖2

流程說(shuō)明

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

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

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

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

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

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

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

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

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

這個(gè)項(xiàng)目已開(kāi)源，大家有興趣可以自己研究或者參照項(xiàng)目編寫自己的聚合SDK

項(xiàng)目地址：https://code.csdn.net/typesdk_code

項(xiàng)目地址：https://github.com/typesdk