1. The client directly verify Apple's recE ip t verify if successful self-paid goods
2. The client will pass receipt server, authenticated by the server and distribute goods
In accordance with the principles of safety, all the information the client is not credible, and the payment is in the business core modules, so you should choose the second.
Under the following brief introduction, the second way is a simple process.
1. The client successful payment, get receipt
2. The client receipt spread to the server
3. apple server to verify receipt successful authentication, payment of receipt of goods
Payment security
As payment, safety comes first, following a brief analysis about the common means of attack.
1, hijacking attacks apple server => by dns pollution, so that the client came to pay fake apple_server, and return to verify a successful response. This is mainly for the payment is a payment if the two will be invalid.
2, repeated validation attacks => a receipt reused many times
3, cross-app attack => other app in the receipt to use our app
4, for the price of attack => cheap goods instead of high-priced goods
5, ambiguity attack => before iap pay status = 0 represents verify success and now become status = 0 can only express receipt legitimate need to decide specific payment details For iOS 6 style transaction receipts by in_app field, the status code reflects the status of the specific transaction's receipt.
6, middle attack => fake apple_server, if the user will pay
Hijacking apple server attack
By dns pollution, so that clients verify through false apple_server, so consider yourself successful payment. The main way to pay for ** a **, if payment is two, no effects. Common iap hack software @iAPFree @iAP Cracker is to use a similar principle.
Repeat validation attacks
Because with a receipt, if the first verification is successful, then after each verification will be successful. If the server is not sentenced to heavy mechanisms, it will lead a receipt to be used as many times recharging process.
To prevent this, we can do a receipt md5 get receipt_md5, every time you send a request to recharge according to receipt_md5 heavy sentence, if repeated stops issuing merchandise.
Cross- app Attack
Get the receipt by the other app, and then sent to our app in. Because this receipt is legitimate and apple does not verify the source of the request, so this can be verified by a receipt.
In this case, we can determine whether the apple apple_callback_data verify the return value corresponding bundle_id of our app bundle_id as to verify.
Price change attack
In the same app, the low-priced goods with the receipt of counterfeit purchase big-ticket items. This time bundle_id and our app is bundle_id is the same.
In view of this situation, we can verify the return value from the corresponding apple_callback_data get in the Apple PR oduct_id, and follow the product_id to recharge. Do not trust product_id ** ** Client
Ambiguity attack
In iOS6 time, status = 0 represents the payment is successful, and now becomes the status = 0 only that on receipt ** ** whole legal.
So, for iOS7 even a back order, will return status = 0, if it is in accordance with the logic of iOS6, will lead to false recharge. For iOS7, we should not only by status, but also by the contents in_app to decide how to deliver the goods.
```
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.
Middle attack
Fake apple server, to forward our request to pay really apple_server, get the legal receipt, and get hold of a fake receipt to the client. This will get a legitimate credentials. With this legal receipt, request forgery others recharge, so as to achieve the purpose of someone else recharge.
For middle attack, the most important thing is to ensure that a user's payment receipt, can not be used by the user b. But the apple in order to protect privacy, receipt does not have any user's personal information, which we need to ensure their own. At present we do this to ensure that encryption means.
iOS detailed process payments
The client got the apple of receipt sent serverserver get the receipt, get Apple to verify the status apple_callback_data if apple_callback_data is 21007, indicating a sandbox mode (no money can buy) To determine the processing logic according to specific needs, needs Note that, ios paid at the time of the audit on the use of sandbox mode.
If the status is apple_callback_data 0, it is necessary from apple_callback_data [ 'receipt'] [ 'in_app'] all the records in this list get each recharge. Transaction_id original_transaction_id then recorded and to prevent the same transaction to be reused.
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
Back to all recharge and repeat the success of transaction_id, there is client to complete transaction
to sum up
Pay as a core module, in addition to technical assurance, business should also be reconciled once a week. If you find that income and server on the apple of income recorded a relatively large gap, we should pay close attention to see why.
Finally, an example of 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"
}
}