Apple IAP security payment and prevention skills

Apple IAP security payment and prevention skills

In the past two days, I have carefully considered several payment security issues during the preparation of our game APP purchases. Any issue involving payment is very sensitive, and it is unacceptable for either party to suffer losses. So here are some important points of payment security. IAP refers to In-App Purchase, which is a payment method, rather than Apple's proprietary payment method. It also has different implementations on other platforms. Here, it targets Apple IAP.

Speaking of IAP security issues, there is an obvious logical vulnerability in Apple's IAP process. This logical vulnerability occurs when we handle it improperly, this will cause problems between the services provided by Alibaba Cloud and players. Let's take a look at the IAP payment sequence diagram:

The entire payment process is as follows:

1. The client requests to the Appstore to purchase the product (assuming the product information has been obtained). After the Appstore verifies the product, the user's Apple account balance will be deducted.

2. Appstore returns a piece of receipt-data to the client, which records the certificate and signature information for this transaction.

3. The client provides receipt-data to game servers that we can trust.

4. The game server performs a base64 encoding for receipt-data.

5. Send the encoded receipt-data to itunes. appstore for verification.

6. itunes. appstore returns the verification result to the game server.

7. The game server issues corresponding item and push data update notifications to the client for the product purchase status and product type.

These seven steps are actually a very safe process. Where is the problem? Let's talk about two verification models for Apple IAP.

IAP built-in Model, local verification

Some stand-alone games or even online games are skipped 3 ~ In step 7, after obtaining receipt-data, the client directly sends a verification request to itunes. appstore, obtains the result, and modifies game data according to the result.

When designing a game, we all follow the truth: "Any data on the client is insecure. Without independent server-assisted verification, you will not be able to avoid the fact that data is modified. Yes, you will make less money. However, it would be terrible if online games do not pass independent server verification, but are notified of the server status after client verification to allow them to issue game items. This is the IAP built-in Model. The logic for security problems is as follows:

void paymentQueue(...){    if (transaction != nullptr)    {        me.money += 1000;    }}

The above Code directly issues products to the game after receiving the successful response, and does not verify the products and documents. If receipt-data is allowed to be locally verified, the free in-house purchase BUG we mentioned may occur. In fact, there are also tools like IAPCracker/IAPFree that exploit this IAP vulnerability. It is too simple for iOS devices that have escaped from jail. You can modify local data without forging or skipping the receipt-data verification.

Isn't it enough to make the process safe? No, but this security guarantee only makes modification difficult. Apple officially provided Validating Receipts Locally to perform security verification on the receipt-data on the client, mainly to verify the validity of the certificate and signature. If you do not want to write code verification on your own, you can also use the receipt-data verification API provided by a third-party organization, which is famous for urbanairship and beeblex.

But if it can forge a completely legal receipt-data, is it the same. Yes, in order to bypass Validating Locally, hackers began to use their own forged receipt-data for the transfer, so there was an in-appstore that could forge "legal orders. Therefore, this method of local enhanced verification cannot completely avoid IAP attacks.

IAP Server Model, Server Verification

 

If we move the verification logic to the server, this process will become much easier. This is because you no longer need to worry about the forgery of receipt-data. However ~ 7. Some naive logic vulnerabilities are also generated on the server:

 

Reponse content for verification of receipt-data is not verified and recorded, and goods are issued directly based on the Product. In this way, as long as the client continuously submits receipt-data, you need to continuously verify and issue the product again according to the normal logic. The safer method is:

After each receipt of receipt-data, the submitted gamer account and the single number in receipt-data are mapped and recorded. Each time the receipt-data is verified, first, determine whether it already exists.

As long as such verification is done, the entire payment process becomes clearer.

Ensure successful submission and Exception Handling of receipt-data

Based on the IAP Server Model, and we know that the mobile phone network is unstable, after the payment is successful, we cannot ensure that the receipt-data will be submitted to the Server. If this happens, it means that the player has been charged by the appstore but has not received any item from the server.

The solution to this problem is to set a return value on the protocol for submitting the receipt-data request so that the server can tell it that it has successfully received and verified the receipt-data. before receiving such a reply, the client must save the receipt-data and initiate a regular request to the server until it receives the reply from the server.

What should I do if the client fails to submit receipt-data? That is, the player is charged, and the purchase receipt of the appstore is received, but the game item is still not received, so the complaint is reported to the game customer service.

This situation also occurs in the past experience, and common disputes between players and game operators occur. The game customer service asks the gamer for the game account and the appstore receipt number, and queries itunes-connect to check whether the order exists. If the order exists, contact the developer to query the game server to check whether the order number corresponds to the player name and whether it has been used, the purpose of this check is to prevent malicious players from using the used order number for deception and lie that they have not received the goods. This is the purpose of the security logic mentioned in the red letter in the above section IAP Server Model. Of course, if you cannot find this order number, it means that this order has not been used, and you can manually send goods to players.