Protection against hacking in-app purchases. Part 2

Recently, I talked about how to protect your application by validating purchases on your server . A couple of days after the post was published, this type of protection was learned to bypass. But there is good news, we now know what the weak points were, and we can strengthen these moments.



What was bad?

• There were not enough checks for compliance with the check and data in SKTransaction .
• There were not enough server response checks.

Apple's VerificationController

I admit, when I wrote my first post, I responded coldly about the method of protection 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 in 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 that are included in the VerificationController:

• Stores all purchases made in the app and checks them for uniqueness, so that it is more difficult to deceive the app with the same absorbed purchases.
• It verifies the certificate and the correctness of the signature of the purchase data so that the receipt we received from the server is correctly signed.
• Checks SKPayment fields in the SKPayment object and in the purchase check match.
• Checks the purchase check on the Apple server, and during the check, checks the extended information from the SSL certificates. Otherwise the connection will not be established.
• The validation request uses a unique secret key for the application. Apple may soon ban keyless checking or checks from purchases from other applications.
• In the server's response, it checks the coincidence of the fields with our check, so that it is impossible to simply return someone else's data and status: 0.

Github already has a slightly doped version of ValidationController-a: github.com/evands/iap_validation . It differs from the standard one in that base64 encoding-decoding has already been implemented in it and convenient delegates have been made in which the paid function can be enabled.

')

What else can you do

If the above is not enough for you and you want to add something of your own to the protection of the application, I can advise a good book on this topic: Hacking and Securing iOS Applications: Stealing Data, Hijacking Software . However, do not get carried away, you can add a weak link to the existing protection and make it worse.

Battle check

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 for non-jailbroken devices come before checking the validity of the check fields, the SKPayment fields SKPayment and are scorching, because check that they slip, completely from another purchase. A pleasant surprise for me was the fact that jailbreaker jailbreakers also could not make a purchase, instead the application crashes at the time of validation. And that means, as long as the protection works, and it works well, let's see how long it takes to break it. :)