Apple gives developers access to its private API to prevent in-app purchase exploit, fix coming in iOS 6

Apple has provided developers with a new document today that outlines a method for preventing the recent in-app purchase exploit that allowed free transactions. We’ve spoken to developers that have reviewed the document and its contents are singular in that Apple gives permission to use its private API in order to enact a fix.

The method for preventing the hack is very similar to the one that we outlined in our original coverage. Namely, Apple says that developers who have been using their own servers to validate receipts, and utilizing encryption procedures to protect the transmission of those receipts, are safe.

Developer Marco Tabini explained this process to The Next Web previously:

The fact is, this would be easy for Apple to solve by providing a method for developers to validate IAP receipts using what’s called a “shared secret,” that is, a piece of information known to both Apple and the developer that is not exchanged as part of the validation process. Coupled with another technique called “salting,” in which each communication is digitally signed in a time-sensitive way, this would make it much harder for someone to subvert the IAP process using a man-in-the-middle attack.

Apple recommends that developers use these secure methods to validate receipts and make sure that the certificate used to connect to the App Store are genuine. Interestingly, this procedure is not included in Apple’s current framework for developers that use in-app purchasing, which is likely why it is giving them access to parts of the API that they would not normally have access to. This allows them to enact a fix immediately, rather than waiting for iOS 6.

Essentially, Apple has added a hash to each transaction that is calculated based on a digital certificate. That certificate must be coded into the app by each developer. This is used to determine whether the in-app purchase receipt has come from Apple directly. The data in the receipt is used to calculate that hash so that each one is unique and can’t be faked.

Note that this method is making up for the fact that Apple doesn’t just provide for this behavior right out of the gate in its own StoreKit code. If the digital signature and validation system had been in place from the beginning, this fix would not have been needed.

Apple is normally very protective of its private APIs, and rejects apps regularly for using even inconspicuous hooks from it. In this case, it is giving explicit permission to developers to dip into its private frameworks in order to enact a quick fix for this problem through the verification of certificates.

We asked Tabini what he thought about the fix. “I’m happy that Apple has stepped up to the plate,” he said, “but I will note that this fix still requires a bit of work to implement, and does not address the issue of duplicate transactions.”

In a statement to Cnet, Apple spokesperson Tom Neumayr said that a fix would be coming in iOS 6:

We recommend developers follow best practices at developer.apple.com to help ensure they are not vulnerable to fraudulent In-App purchases. This will also be addressed with iOS 6.

Note that this document is accessible to the public, it is not a private developer document, so we are including a link to it here.