Open Radar

 
Summary:
My IPWorldTV app (Apple ID 488282895) has been receiving IAP receipts for Cut The Rope (Apple ID 450542233) for some unknown reason. To verify the receipt I've been sending it and my shared secret to the App Store, but the App Store always returns that the receipt is valid even if my shared secret is not.


Steps to Reproduce:
You can reproduce the issue by taking a valid non-renewable subscription receipt and validating it according to the IAP Programming Guide:
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/VerifyingStoreReceipts/VerifyingStoreReceipts.html

I've been reproducing it on the command-line with curl:
$ curl -d '{"receipt-data": "<RECEIPT>", "password": "INVALID_SHARED_SECRET"}' https://buy.itunes.apple.com/verifyReceipt

You can use the attached receipt to replace "<RECEIPT>" in the command-line above.


Expected Results:
I expect the App Store to mark transactions as invalid if the shared secret does not match the receipt, even for non-renewable subscriptions.


Actual Results:
The App Store ignores the shared secret for non-renewable subscriptions and marks the receipt as valid.


Regression:

Notes:
I understand that the IAP Programming Guide only mentions the shared secret in association with auto-renewable subscriptions, but that leaves a large security hole since the shared secret is ignored for all other transactions. If you follow the In-App Purchase Receipt Validation on IOS guide (see http://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_ReceiptValidation/_index.html), it always sends the shared secret to verify the receipt and if the shared secret is ignored then you could be receiving a transaction for any app on the App Store.

By adding support for the shared secret for all transactions in the verifyReceipt request, it provides an additional layer of security against third-party or iOS bugs and makes it more difficult for future attacks on IAP.