Protection against hacking in-app purchases. Part 2
Recently, I talked about how to protect my application with the validation of purchases on my server . A couple of days after the publication of the post, this type of protection was learned to circumvent. But there is good news, we now know what were the weak points, and we can strengthen these points.
What was bad?
There were not enough checks for compliance with the check and the data in
- There were not enough server response checks.
I admit, when I wrote my first post, I spoke coldly about the protection method proposed by Apple . Like, their protection is vulnerable, because they are still doing a check on their server. Thus, if they can deceive this server, the protection will be broken for all applications that used it. It sounds reasonable, but if you look closely, the chance of such a scenario is not so great, because VerificationController is not only sending a request to the server and checking the result.
Here are the checks included in the VerificationController:
- It saves all purchases made in the application and checks for uniqueness, so that it is more difficult to deceive the application with the same absorbed purchases.
- Checks the certificate and the signature of the purchase data so that the receipt that we received from the server is correctly signed.
Checks if the fields in the object
SKPaymentand in the purchase receipt
- Checks the purchase receipt on the Apple server, and during the check, checks the extended information from SSL certificates. Otherwise, the connection will not be established.
- The validation request uses a secret key that is unique to the application. Perhaps soon Apple will prohibit keyless verification or verification of receipts from purchases of other applications.
- In the response, the server checks the coincidence of the fields with our check so that it is impossible to simply return other people's data and status: 0.
Github already has a slightly dubbed version of ValidationController-a: github.com/evands/iap_validation . It differs from the standard one in that base64 encoding-decoding is already implemented in it and convenient delegates are made in which you can enable a paid function.
What else can be done
If the above does not seem to you enough and you want to add something of your own to protect the application, I can recommend a good book on this topic: Hacking and Securing iOS Applications: Stealing Data, Hijacking Software, and How to Prevent It . However, do not get carried away, you can add a weak link to the existing protection and make it worse.
A couple of days ago the store released version 2.2.1 of my application and I have some statistics. The current methods of hacking non-jailbroken devices reach the check that the fields of the check correspond to the fields
SKPaymentand get scorched, because the check they palm off is from a completely different purchase. A pleasant surprise for me was the fact that jailbreakers for jailbroken devices also can’t make a purchase, instead the application crashes at the time of validation. This means that while the protection is working, and it is working well, let's see how long it takes to break it. :)