The pitfalls of payment in iOS apps

Reprinted from: http://www.leiphone.com/iap-traps.html

After the Spring Festival this year, we launched a new online Intelligent Question Bank: yuantiku. Yuantiku has now launched two products for the civil service examination and application, including the web, iOS, and Android platforms. This time we tried to make a paid product, so we integrated the in-app payment (IAP) function on iOS. We have encountered some pitfalls in IAP during and after the development and launch, so I would like to share with you here.

IAP audit-related pitfalls

I wrote the detailed steps for IAP development in another blog. This section describes the problems encountered during review.

Incorrect IAP type

Because we are a paid product on a monthly basis, I have no experience in setting the IAP type, but I simply set it to a Consumable IAP project. However, I don't know, Apple should use Non-Update Subscription for such time-based products. This type setting error causes an app review to be rejected.

IAP verification Logic

Because Apple has an IAP bug below iOS5.0, attackers can forge a successful payment credential. The iOS6.0 system can also forge creden after jailbreak, so we have added server-side verification for In-app payment. The server sends the payment credential to the Apple Server for secondary verification to ensure that the credential is true and valid.

In our company's test server, we will connect Apple's test server (https://sandbox.itunes.apple.com/verifyReceipt) for verification.

In our deployed online official server, we will connect to Apple's official server (https://buy.itunes.apple.com/verifyReceipt) for verification.

We submitted the formal version to Apple for review. We thought that during Apple review, we should connect Apple's online verification server to verify the purchase credential. As a result, I got it wrong. When Apple reviews the App, it only buys it in the sandbox environment, and the purchase credential generated by it can only be connected to Apple's test and verification server. However, the approved app is connected to our online server. Therefore, the servers on our side cannot be verified and purchased through IAP, causing another rejection of our app review.

The solution is to determine the return code of the server officially verified by Apple. If it is 21007, connect to the test server again for verification. This document of Apple provides a detailed description of the returned code.

Situation after IAP goes online

We added the logic to verify whether the IAP is valid on the server side. After the product was launched, as we expected, we received a large number of fraudulent purchases, which were identified by our servers, but we also encountered the following unexpected situations:

1. Because the proportion of jailbreak users in China is relatively large (about 50%), even though our server will verify the purchase credential, more than 50% of the creden。 are forged every day. At the same time, because Apple's verification server is in the United States, the response time of the Credential verification request is slow, and a large number of forged creden。 are sent to the Apple Server. I don't know if it will be considered by Apple to be malicious DDOS attacks. At least we find that sometimes the verification request times out.

2. Since there are many Chinese users, their mobile phones have been jailbroken by the channel vendors since they purchased them and the IAP free plug-in has been installed. Therefore, even if they want to pay for the service, they cannot pay normally because the system's original IAP payment function has been damaged. The trouble is that they will think this is a problem with our app and then call our customer service to complain. This makes us very depressed.

3. Apple's verification server sometimes has a problem. We found that the JSON data originally agreed to return several times is actually an XML file. This causes us to fail to verify the normal paid IAP credential. Therefore, it is necessary to record all verification creden。 on the server to prevent repeated replay attacks on the same successful creden。. Second, You can manually verify the creden。 when necessary.

The jailbreak mobile phone may be stolen by hackers!

We found that some users reported that they had received Apple's fee deduction bill. However, we can see from the server's verification records that the token he uploaded was false. Since there were not many of these users, we initially thought that they were maliciously deceiving us. Then we asked him to forward Apple's payment Bill email to us, as well as forwarding iTunes purchase records to us, we are increasingly skeptical that there is a black industry chain. The normal purchase credential of the jailbreak mobile phone may be intercepted by malicious programs. The specific attack method is discussed as follows:

1. After the jailbreak mobile phone is cracked, it may have installed malicious programs from some cracking channels.

2. the hacker will send all HTTPS requests from the jailbroken mobile phone to his intermediate server.

3. when there is a payment request, the hacker first sends the request to the Apple Server. After Apple returns the successful credential, the hacker replaces the credential with a false credential to steal the full payment credential.

Someone may ask, what is the purpose of this credential? To protect users' privacy, the payment credential does not contain the Apple id of any user. Therefore, our app and server cannot know who bought the credential, you can only know whether the credential is true or false. Then hackers can use this credential to notify us that the purchase has been completed in another account, and the verification credential sent is true, therefore, our server will mistakenly assume that the hacker's account has completed the purchase, and then calculate the membership period on the hacker's account.

For another simple example, you bought a 500 yuan shopping coupon with 500 yuan. Because the coupon is not named by name, you cannot know who bought it. If a voucher is dropped during the issuance process, the person who steals the voucher can take the stolen real shopping coupon for shopping. The discount card is not named, so it cannot be verified. In this example, the absence of a shopping voucher is the same as that of an Apple payment credential without an account.

In view of the above situation, considering that the jailbreak mobile phone cannot be successfully paid, there are security issues, so we canceled the IAP payment function in the new version.

Therefore, we recommend that you do not jailbreak your mobile phone. It is highly risky to jailbreak your iPhone. It is really not worth losing security to play a few games for free.