1. 客戶端直接verify蘋果的receipt 如果verify成功 自行發(fā)放商品

2. 客戶端將receipt傳給server,由server進(jìn)行驗(yàn)證并發(fā)放商品

按照安全性原則, 客戶端的所有信息都是不可信的,而且支付是業(yè)務(wù)中的核心模塊,所以應(yīng)該選擇第二種。

下面簡(jiǎn)要介紹下,第二種方式的簡(jiǎn)單流程。

1. 客戶端支付成功,拿到receipt

2. 客戶端將receipt傳到服務(wù)端

3. 服務(wù)端去apple驗(yàn)證receipt 如果驗(yàn)證成功 就發(fā)放receipt中的商品

支付安全性

作為支付,安全性是第一位的，下面簡(jiǎn)要分析一下常用的攻擊手段。

1、劫持apple server攻擊 => 通過dns污染,讓客戶端支付走到假的apple_server,并返回驗(yàn)證成功的response。 這個(gè)主要針對(duì)支付方式一?如果是支付方式二 就無效。

2、重復(fù)驗(yàn)證攻擊 => 一個(gè)receipt重復(fù)使用多次

3、跨app攻擊 => 別的app的receipt用到我們app中來

4、換價(jià)格攻擊 => 低價(jià)商品代替高價(jià)商品

5、歧義攻擊 => iap支付之前的status=0表示verify成功 而現(xiàn)在變?yōu)閟tatus=0只能表示receipt合法 具體支付詳情需要通過in_app字段決定 For iOS 6 style transaction receipts, the status code reflects the status of the specific transaction’s receipt.

6、中間人攻擊 => 偽造apple_server,如果用戶支付就將

劫持apple server攻擊

通過dns污染,讓客戶端通過假的apple_server進(jìn)行verify,從而認(rèn)為自己支付成功。這個(gè)主要針對(duì)**支付方式一**,如果是支付方式二,就沒效果了。常見的iap hack軟件@iAPFree @iAP Cracker 就是用的類似原理。

重復(fù)驗(yàn)證攻擊

因?yàn)橥粋€(gè)receipt,如果第一次驗(yàn)證成功,那么之后每次驗(yàn)證都會(huì)成功。如果服務(wù)端沒有判重機(jī)制,就會(huì)導(dǎo)致一個(gè)receipt被當(dāng)做多次充值處理。

為了預(yù)防這種情況,我們可以將receipt做一次md5得到receipt_md5, 每次發(fā)送充值請(qǐng)求的時(shí)候就按照receipt_md5判重,如果重復(fù)就停止商品發(fā)放。

跨app攻擊

通過在別的app中拿到receipt,然后發(fā)送到我們app中。因?yàn)檫@個(gè)receipt是合法的而且apple不會(huì)驗(yàn)證請(qǐng)求的源,所以這個(gè)receipt是可以驗(yàn)證通過的。

對(duì)于這種情況,我們可以判斷apple verify的返回值apple_callback_data中對(duì)應(yīng)的bundle_id和我們app的bundle_id是否一樣來進(jìn)行驗(yàn)證。

換價(jià)格攻擊

在同一個(gè)app中,用低價(jià)商品的receipt偽造購(gòu)買高價(jià)商品。這時(shí)候bundle_id和我們app的bundle_id是一致的。

針對(duì)這種情況, 我們可以從apple verify的返回值apple_callback_data中拿到對(duì)應(yīng)的PRoduct_id, 并按照product_id來進(jìn)行充值。 **不要信任客戶端的product_id**

歧義攻擊

在iOS6的時(shí)候,status=0表示此次支付成功,而現(xiàn)在變?yōu)閟tatus=0只表示receipt**整體上**合法。

所以,對(duì)iOS7即使是一個(gè)過期訂單,也會(huì)返回status=0,如果還按照iOS6的邏輯處理,就會(huì)導(dǎo)致假充值。針對(duì)iOS7,我們應(yīng)該不只通過status,還要通過in_app中的內(nèi)容,來決定如何發(fā)放商品。

```

For iOS 6 style transaction receipts, the status code reflects the status of the specific transaction’s receipt.

For iOS 7 style app receipts, the status code is reflects the status of the app receipt as a whole. For example, if you send a valid app receipt that contains an expired subscription, the response is 0 because the receipt as a whole is valid.

中間人攻擊

偽造apple server,將我們的支付請(qǐng)求轉(zhuǎn)發(fā)到真的apple_server,拿到合法的receipt,并弄個(gè)假的receipt給客戶端。這樣就拿到一個(gè)合法的憑證。利用這個(gè)合法的receipt,偽造別人充值的請(qǐng)求,從而達(dá)到幫別人充值的目的。

針對(duì)中間人攻擊,最重要的是保證a用戶的支付receipt,不能被b用戶使用。但是apple為了保護(hù)隱私,receipt中沒有任何用戶的個(gè)人信息,這就需要我們自己來保證。目前我們用加密的手段來做這個(gè)保證。

iOS支付的詳細(xì)流程

客戶端拿到apple的receipt 并發(fā)送到serverserver拿到這個(gè)receipt,向蘋果驗(yàn)證得到apple_callback_data如果apple_callback_data的status是21007,說明是沙盒模式(不用花錢就可以購(gòu)買) 要根據(jù)具體需求判斷處理邏輯,需要注意的是,ios的審核在支付的時(shí)候就采用的沙盒模式。

如果apple_callback_data的status是0,就要從apple_callback_data[‘receipt’][‘in_app’]這個(gè)list中拿到所有的記錄,每一個(gè)進(jìn)行充值。然后記錄transaction_id和original_transaction_id來防止同一個(gè)transaction被重復(fù)使用。

https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Restoring.html

https://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html#//apple_ref/doc/uid/TP40010573-CH106-SW1 => Original Transaction Identifier

返回所有充值成功和重復(fù)的transaction_id, 有client來complete transaction

總結(jié)

支付作為核心模塊,除了技術(shù)上的保證,商務(wù)也應(yīng)該每周進(jìn)行一次對(duì)賬。如果發(fā)現(xiàn)apple上的收入和服務(wù)端記錄的收入有比較大的差距,就應(yīng)該抓緊查看原因。

最后給出一個(gè)apple_callback_data的例子

{

"status": 0,

"environment": "Production",

"receipt": {

"download_id": 75017873837267,

"adam_id": 1149703708,

"request_date": "2017-01-13 06:57:20 Etc/GMT",

"app_item_id": 1149703708,

"original_purchase_date_pst": "2016-11-17 18:57:09 America/Los_Angeles",

"version_external_identifier": 820252187,

"receipt_creation_date": "2017-01-13 05:04:52 Etc/GMT",

"in_app": [

{

"is_trial_period": "false",

"purchase_date_pst": "2017-01-12 21:04:52 America/Los_Angeles",

"original_purchase_date_pst": "2017-01-12 21:04:52 America/Los_Angeles",

"product_id": "com.lucky917.live.gold.1.555",

"original_transaction_id": "350000191094279",

"original_purchase_date": "2017-01-13 05:04:52 Etc/GMT",

"original_purchase_date_ms": "1484283892000",

"purchase_date": "2017-01-13 05:04:52 Etc/GMT",

"purchase_date_ms": "1484283892000",

"transaction_id": "350000191094279",

"quantity": "1"

}

],

"original_purchase_date_ms": "1479437829000",

"original_application_version": "26",

"original_purchase_date": "2016-11-18 02:57:09 Etc/GMT",

"request_date_ms": "1484290640800",

"bundle_id": "com.lucky917.ios.Live",

"receipt_creation_date_pst": "2017-01-12 21:04:52 America/Los_Angeles",

"application_version": "32",

"request_date_pst": "2017-01-12 22:57:20 America/Los_Angeles",

"receipt_creation_date_ms": "1484283892000",

"receipt_type": "Production"

}

}

總結(jié)

以上是生活随笔為你收集整理的iap java md5_苹果应用内支付(iOS IAP)的流程与常用攻击方式的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。