So, now is IAP hacked also…
http://www.macworld.com.au/news/hacker-exploits-ios-flaw-for-free-in-app-purchases-63628/
[import]uid: 81188 topic_id: 28672 reply_id: 328672[/import]
Well that’s great. Hopefully it’ll be fixed sooner than later. [import]uid: 151050 topic_id: 28672 reply_id: 115602[/import]
IAP was hacked looooooong time ago.
https://twitter.com/elevatefun/status/182138586785787904
Just verify transaction on your server with https://buy.itunes.apple.com/verifyReceipt and not standard Corona SDK API:
http://developer.coronalabs.com/code/validation-auto-renewable-app-purchases
https://github.com/SatheeshJM/Auto-Renewable-In-App-Purchase-Validation-using-Corona-SDK/blob/master/validate.php [import]uid: 12704 topic_id: 28672 reply_id: 115617[/import]
This is old news man. IAP has been hacked for ages! [import]uid: 29181 topic_id: 28672 reply_id: 115622[/import]
from the article:---------------
More to the point, app makers are more likely to rely on Apple’s receipt validation approach than building their own solution. “I’m willing to bet that 99 percent of all developers validate on iOS because it’s a lot of extra work to setup a server that does the validation,” developer Craig Hockenberry told us.
This is the point I made on the php thread. ALL apps that use receipt verification to deny the hack have to verify the receipt through a server using base64 and SSL as it connects with Apple to complete the process. If an app uses SSL, the App has to be registered with the US.gov for to satisfy export compliance laws. This means any app that verifies a receipt, whether on device or through a server use SSL and require registration.
I went through setting up the receipt validation through my own server last week to deny this IAP hacking method and while researching how to do it, I discovered the encryption export regulations that I was oblivious to.
I agree with the articles author, I’m thinking the VAST majority of IAP receipts are either not even verified or if done are executed on the device where the spoof Apple server sends another fraudulent status:0 reply.
This is also why I suggested Corona provide and API, with a URL encryption generator, that developers could use to encrypt their URL’s placed in network.request. As pirating/ hacking get more sophisticated, these exposed URL’s will be exploited IMO.
[import]uid: 106779 topic_id: 28672 reply_id: 115637[/import]
After reading a few more articles/comment on this latest variation of the IAP Hack, which is different because it doesn’t require a jail broken device, Apple has a huge problem.
While I was working my way through the IAP and receipt verification for the App I’m building, I was constantly thinking to myself, “this is ridiculous”!
The complexity and effort ALL Devs have to go through to insure the “purchase” callback is legitimate doesn’t make sense. I mean, why can’t this be done by the iOS automatically in the background to produce a “reliable” status:0?
The bottom line is Apple can’t guarantee communication between it’s proprietary Hardware, which uses it’s proprietary iOS, and it’s proprietary AppStore, which is almost a proprietary economy, it uses to make transactions. It’s simply 1 proprietary system and Apple can’t verify it’s devices are communicating with it’s own online store?
This is a GIANT security hole that is being exploited and Apple hands off the responsibility to Devs to protect against any possible exploits of the security hole? It won’t be long before the 3rd party verification system, which Apple should handle internally and automatically, is also exploited.
Devs don’t have any choices where they can sell their iOS Apps. It’s the AppStore or nothing. Apple gets a huge commission on each sale, there is plenty of $ to do this securely. IMO, it’s Apples responsibility to insure it’s proprietary “End to End System” is secure and when a purchase is made, it is verified automatically by Apple as legitimate.
[import]uid: 106779 topic_id: 28672 reply_id: 115681[/import]