The security of iOS in-app purchases is a hot topic after an IAP hacking server was launched last week by a Russian developer. When The Next Web talked to Alexey Borodin, he told them he’s since turned the service over to an unnamed third party — and, as of that conversation, he’d collected only $6.78 in donations to cover his costs.
While we strongly advised users to steer clear of this theft-of-service hack, that doesn’t solve the problem for developers waiting on Apple to come up with a fix. In the interim, indie startup Beeblex may provide a validation workaround for developers.
Some background: The underlying framework for all IAPs in iOS is StoreKit, covered in depth in my iOS Cookbook. Every successful StoreKit purchase transaction contains a receipt. This receipt, which is sent in raw NSData format, corresponds to an encoded JSON string. It contains a signature and purchase information.
Apple strongly recommends that you validate all receipts with their servers to prevent hacking and ensure that your customers actually purchased the items they are requesting.
You POST a request to one of Apple’s two servers. The URL you use depends on the deployment of the application. Use buy.itunes.apple.com for production software and sandbox.itunes.apple.com for development.
The request body consists of a JSON dictionary. The dictionary is composed of one key (“receipt-data”) and one value (a Base64-encoded version of the transaction receipt data). I normally use the CocoaDev NSData Base 64 extension to convert NSData objects into Base64-encoded strings. CocoaDev provides many great resources for Mac and iOS developers.
A valid receipt returns a JSON dictionary. The receipt includes the transaction identifier, a product ID for the item purchased, a unique ID, the bundle ID for the host application, and a purchase date. Most importantly, it returns a status. A valid receipt always has a 0 status. Any number other than 0 indicates that the receipt is invalid.
Simply checking for the status may not be sufficient for validation. It’s not too difficult to set up a proxy server to intercept calls to the validation server and return JSON {“status”:0} to all requests. What’s more, the receipt data that is sent along with the validation request can be easily deserialized. For that reason, always use receipt validation cautiously and as part of the overall purchase process, where it’s less likely that proxy servers can override communications with Apple.
Enter Beeblex. They just launched a free IAP validation service for iOS apps that, according to their marketing text, “verifies IAP receipts against Apple’s servers” using time-limited tokens and strong encryption to limit IAP purchase end-runs.
Encryption prevents “man in the middle” attacks; time limited tokens prevent replay attacks. Together they make it much less likely that a simple proxy could successfully spoof an IAP reciept and fool your app into providing something for nothing.
It’s an intriguing option. The advantage seems to be that Beeblex provides a server component for apps developed without one. Still, I’m not sure I’d want my apps to rely on a third party service when any service interruption could create a large angry user base.
I wonder how Beeblex will pay for the bandwidth necessary to facilitate this service, and what would happen should they get hacked. Hacking could be a big deal, because it’d circumvent potentially hundreds or thousands of apps, instead of just one.
[Update] Marco Tabini, one of the Beeblex developers, writes, “One thing that I wanted to point out is that we have, in fact, thought about the possibility that our service may go down by building methods inside the SDK that would inform the app of transaction failures due to networking errors. Of course, you are completely right that we need to show that we can grow and maintain the service, and we have a lot of work ahead of us in this respect. We’ll do our best!”
I’d probably feel a lot more comfortable buying from a well-known quantity than relying on a free start-up. Urban Airship doesn’t appear to provide this kind of service. I gave them a call and a sales guy said it’s not an option. [Update] CEO Scott Kveton replied to my email saying, “Yes we do IAP receipt verification.”
He adds a note from his team: “This is not really a security problem. It’s long been known that you can put your own root CA on iPhones, and at that point you can basically do anything as a proxy. The people being bitten by this on the IAP side are only those that are not doing receipt verification with Apple out of band via a server, which is something we do in our IAP product as a standard. If you do out of band receipt verification, this fails and nothing is purchased/granted.”
My feelings on IAP and piracy are this (in no particular order):
- Developers use IAP too much, and often without regard for the user experience. Requiring IAP in apps for kids is, in my opinion, evil — it should be strongly discouraged by Apple policy. If your app requires IAP to bypass gameplay segments, your game design needs some serious reconsideration.
- Focus on providing good experiences for your paying users instead of fighting piracy. If your anti-piracy protections tick off even one paying customer you have lost the war.
- Trying to fight piracy is a losing proposition with one exception. The one exception is scalable server support. If pirates are killing your servers, either find another app to build or try to limit the impact of unpaid customers.
- Don’t save IAP unlocks in plain text files. There are keychains and other more secure solutions available.
DevJuice: Beeblex offers in-app purchase validation services originally appeared on TUAW – The Unofficial Apple Weblog on Wed, 18 Jul 2012 18:15:00 EST. Please see our terms for use of feeds.
Source | Permalink | Email this | Comments