<http://schema.org/articleBody>
"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.\r\n\r\nThe 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\u00A0receipts, and utilizing encryption procedures to protect the transmission of those\u00A0receipts, are safe.\r\n\r\nDeveloper\u00A0Marco Tabini\u00A0explained this process to The Next Web previously:\r\nThe fact is, this would be easy for Apple to solve by providing a method for developers to validate IAP receipts using what\u2019s called a \u201Cshared secret,\u201D that is, a piece of information known to both Apple and the developer that is not exchanged as part of the validation process.\u00A0Coupled with another technique called \u201Csalting,\u201D 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.\r\nApple recommends that developers use these secure methods to validate\u00A0receipts\u00A0and 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\u00A0developers\u00A0that 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.\r\n\r\nEssentially, 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\u00A0receipt\u00A0has come from Apple directly. The data in the\u00A0receipt\u00A0is used to calculate that hash so that each one is unique and can't be faked.\r\n\r\nNote 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.\r\n\r\n\r\n\r\nApple is normally very protective of its private APIs, and rejects apps regularly for using even\u00A0inconspicuous 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.\r\n\r\nWe asked Tabini what he thought about the fix. &amp;quot;I'm happy that Apple has stepped up to the plate,&amp;quot; he said, &amp;quot;but I will note that this fix still requires a bit of work to implement, and does not address the issue of duplicate transactions.&amp;quot;\r\n\r\nIn a statement to Cnet, Apple spokesperson Tom Neumayr said that a fix would be coming in iOS 6:\r\nWe 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.\r\nNote that this document is accessible to the public, it is not a private developer document, so we are including a link to it here."^^<http://www.w3.org/2001/XMLSchema#string>
<http://thenextweb.com/apple/2012/07/20/apple-gives-developers-access-to-its-private-api-to-prevent-in-app-purchase-exploit-says-fix-coming-in-ios-6/>