Apple provides details, fixes on in-app purchase hack

In the wake of the revelation of the recent App Store <a href="http://macnn.com/rd/262894==http://www.ipodnn.com/articles/12/07/13/company.is.investigating.problem.no.fix.yet/" rel='nofollow'>in-app purchase hack</a>, Apple has published a document for developers on how to protect applications from purchase fraud. The document addresses three common questions about the security process, as well as providing APIs to eliminate the flaws that allowed the hack to function. Additionally, in the same document, Apple said iOS 6 will completely rectify the issue.<br><br>If a developer's application performs validation by connecting to the developer's server directly, Apple claims that as long as the developer has followed best practices and receipt validation by having the developer's server perform the validation with the App Store server, then the app isn't affected by the attack as it does not connect to the App Store server directly.

If an app connects to the App Store server directly, Apple suggests that the developer change to having the app connect to the developer's server and have that server connect to the App Store server. If code revision isn't possible, then basic security checks like verifying unique receipt IDs, the App Store SSL server certificate is an EV certificate.

Developers concerned about completed transactions are advised to revalidate receipts for consumable items, like in-game currency, assuming the developer has retained the receipts. Permanent items, known as nonconsumables, can be re-checked after a restore operation.

While non-public APIs are generally not allowed in iOS applications, Apple has made a one-time exception for fixes to prevent the hack from functioning. A four-step process including two additional files has been provided to close the back door the hackers used to allow free in-app purchases.

First <a href="http://macnn.com/rd/262895==http://www.ipodnn.com/articles/12/07/13/company.is.investigating.problem.no.fix.yet/" rel='nofollow'>publicized a week ago</a>, the hack required that users hand over iTunes account information to the Russian hacker organization, making it a risky venture. Today's updates to the developer's community is the first fix for the problem. Prior versions of iOS 6 were susceptible to the hack, making future versions of the underway beta likely for first practical implementation on a user-level of the fix.


<div align="center"><img src="http://photos.macnn.com/article_images/article_thumbnail/iOS-in-app-purchase-cracked.jpg" /></div>

Well that's nice. Of course, not everyone will upgrade, and so that'll leave it up to all developers to basically have to fix their software (because we can't get Apple to fix their current OS, I guess).

Oh, this is rich. Apple first insists ALL developers use Apple's store to perform all in-app transactions. But then the developer still needs to have their own server in which all transactions are run through.

Um, why not just let the developer handle the transaction themselves, then? Oh, right, because Apple wants their cut of the pie. Can't have people making money if Apple can't get part of the action!


And I'm glad to see Apple following really secure principles, like making sure the connection is to their secure server, or actually encrypting credentials before transmitting them. You know, crazy stuff.

iOS upgrade rates are notoriously fast.

So whatever small percentage of users remains on previous OS versions will have to then a) WANT to cheat the system, and then b) FIND a proxy server that will still perform this hack, and then c) be prepared to send their account details through that server.

This whole thing was more of a proof-of-concept than a real danger.

It needs to be fixed, but I doubt developers are *really* losing sleep over it.

You fail to realize that the 30% cut Apple takes in exchange for dealing with international distribution, payment, sales tax, book-keeping, and local laws and regulations, is actually a DAMN GOOD DEAL, especially for smaller developers.