Protection against universal in-app shopping hacks
The protection method described below was hacked; read the continuation of this post: Protection against hacking in-app purchases. Part 2 .
Not so long ago, news about the activation of in-app purchases for free and even without a jailbreak made noise. The idea is simple: ssl certificates are installed into the system and a custom dns server is written, which will send requests to the apple servers to the server. The hackers server will confirm the purchase and it will successfully activate on the device. After the release of this news, there was a lot of panic and Apple even had to do something and tell the developers how to protect their application . In fact, the problem was not new, on jailbroken devices it was possible to activate in-app purchases for free for a long time. The solution to the problem is also not new, it is described in the Apple documentation, but no one bothered with practical implementation. About my version of such protection and will be discussed below.
There are two possible scenarios. Plain:
The device activates the purchase through the apple server without additional validation and participation of the developer server.
')
Complicated:
Developer server can participate in the purchase process as follows:
We are interested in steps 10-11, because it is on them that we can help the device determine whether the check was issued by the apple server or is it a fake.
We can validate the purchase check only on the Apple server. To do this, send JSON with a check encoded in base64, inside the HTTP POST request:
On one of the Apple servers:
In response, the server will return the validation status, and, if validation is successful, the decoded check fields:
Understanding the mechanics described above, it was not difficult to write a proxy application for ruby, which forwards validation requests to one of Apple's servers. I posted the ready-to-use application code on github . I will be glad to improve and pull requests. You can also touch it on heroku: https://receiptValidator.heroku.com/validate , using a test check from the repository. With a tick sandbox you can see the correct answer, and without it - the error code.
In the application, we analyze the response of our server and decide whether to activate the built-in functions, or it is a suspicious check and can be ignored. If interested, in the next article I will write about the protection inside the application.
PS A little unscrupulous samopiara: this protection was written specifically for Galileo Offline Maps and was successfully tested in version 2.2, which appeared in the AppStore yesterday morning.
Not so long ago, news about the activation of in-app purchases for free and even without a jailbreak made noise. The idea is simple: ssl certificates are installed into the system and a custom dns server is written, which will send requests to the apple servers to the server. The hackers server will confirm the purchase and it will successfully activate on the device. After the release of this news, there was a lot of panic and Apple even had to do something and tell the developers how to protect their application . In fact, the problem was not new, on jailbroken devices it was possible to activate in-app purchases for free for a long time. The solution to the problem is also not new, it is described in the Apple documentation, but no one bothered with practical implementation. About my version of such protection and will be discussed below.
How in-app purchases work
There are two possible scenarios. Plain:
The device activates the purchase through the apple server without additional validation and participation of the developer server.
')
Complicated:
Developer server can participate in the purchase process as follows:
- sends a list of potential purchases (step 2),
- validates the poku check (steps 10-11),
- provides access to some additional content (steps 13-14).
We are interested in steps 10-11, because it is on them that we can help the device determine whether the check was issued by the apple server or is it a fake.
Here we must add that the source code from the Apple article can help with the validation of the check directly from the application, but this protection is not very reliable, because no one bothers to redirect requests to the validating server to the address of the attackers' server, which will return the expected response.
Validation
We can validate the purchase check only on the Apple server. To do this, send JSON with a check encoded in base64, inside the HTTP POST request:
{
"receipt-data" : "(receipt bytes here)"
}
On one of the Apple servers:
- sandbox.itunes.apple.com/verifyReceipt - for test purchases from sandbox
- buy.itunes.apple.com/verifyReceipt - for purchases from the AppStore.
In response, the server will return the validation status, and, if validation is successful, the decoded check fields:
{
"status" : 0,
"receipt" : { (receipt here) }
}
From theory to practice
Understanding the mechanics described above, it was not difficult to write a proxy application for ruby, which forwards validation requests to one of Apple's servers. I posted the ready-to-use application code on github . I will be glad to improve and pull requests. You can also touch it on heroku: https://receiptValidator.heroku.com/validate , using a test check from the repository. With a tick sandbox you can see the correct answer, and without it - the error code.
In the application, we analyze the response of our server and decide whether to activate the built-in functions, or it is a suspicious check and can be ignored. If interested, in the next article I will write about the protection inside the application.
Dry total
- Validating purchases through your server makes the application “special” and universal lo-gadgets stop working.
- Hacking the application is still possible, but for this you need to break our application.
- If someone spends time and hacks purchases - you can add additional encryption in communication with our server.
- Free on heroku we get convenient ruby ​​hosting and https encryption.
PS A little unscrupulous samopiara: this protection was written specifically for Galileo Offline Maps and was successfully tested in version 2.2, which appeared in the AppStore yesterday morning.
Source: https://habr.com/ru/post/148638/
All Articles