Confirmation of purchase when purchasing the application

Apple offers two validation documents for receipts with clearly conflicting statements.

In " Checking receipt receipts" :

Note. In iOS, the contents and format of the store receipt are private and subject to change. Your application should not attempt to analyze receipt data directly .

However, in “ Checking the receipt of purchases in the application on iOS ”, an example code is provided in which the procedure for receiving the store is verified and verified as part of the “mitigation strategy” for the security vulnerability:

// Check the validity of the receipt. If it checks out then also ensure the transaction is something // we haven't seen before and then decode and save the purchaseInfo from the receipt for later receipt validation. - (BOOL)isTransactionAndItsReceiptValid:(SKPaymentTransaction *)transaction { if (!(transaction && transaction.transactionReceipt && [transaction.transactionReceipt length] > 0)) { // Transaction is not valid. return NO; } // Pull the purchase-info out of the transaction receipt, decode it, and save it for later so // it can be cross checked with the verifyReceipt. NSDictionary *receiptDict = [self dictionaryFromPlistData:transaction.transactionReceipt]; NSString *transactionPurchaseInfo = [receiptDict objectForKey:@"purchase-info"]; NSString *decodedPurchaseInfo = [self decodeBase64:transactionPurchaseInfo length:nil]; NSDictionary *purchaseInfoDict = [self dictionaryFromPlistData:[decodedPurchaseInfo dataUsingEncoding:NSUTF8StringEncoding]]; NSString *transactionId = [purchaseInfoDict objectForKey:@"transaction-id"]; NSString *purchaseDateString = [purchaseInfoDict objectForKey:@"purchase-date"]; NSString *signature = [receiptDict objectForKey:@"signature"]; // Convert the string into a date NSDateFormatter *dateFormat = [[NSDateFormatter alloc] init]; [dateFormat setDateFormat:@"yyyy-MM-dd HH:mm:ss z"]; NSDate *purchaseDate = [dateFormat dateFromString:[purchaseDateString stringByReplacingOccurrencesOfString:@"Etc/" withString:@""]]; if (![self isTransactionIdUnique:transactionId]) { // We've seen this transaction before. // Had [transactionsReceiptStorageDictionary objectForKey:transactionId] // Got purchaseInfoDict return NO; } // Check the authenticity of the receipt response/signature etc. BOOL result = checkReceiptSecurity(transactionPurchaseInfo, signature, (__bridge CFDateRef)(purchaseDate)); if (!result) { return NO; } // Ensure the transaction itself is legit if (![self doTransactionDetailsMatchPurchaseInfo:transaction withPurchaseInfo:purchaseInfoDict]) { return NO; } // Make a note of the fact that we've seen the transaction id already [self saveTransactionId:transactionId]; // Save the transaction receipt purchaseInfo in the transactionsReceiptStorageDictionary. [transactionsReceiptStorageDictionary setObject:purchaseInfoDict forKey:transactionId]; return YES; } 

If I understand correctly, if I check the receipt, my application will stop working when Apple decides to change the format of the receipt.

And if I don’t check the receipt, I don’t follow Apple’s mitigation strategy and my application is vulnerable to attacks.

Damned if I do this, damned if I don't. Is something missing?

+4
source share
2 answers

They strongly recommend using your own server as an intermediary for verification, as this will allow a clear and secure passage to the App Store for all versions of iOS. This is really the best way to not be damned anyway.

If you must validate directly from the device in the App Store, you only use the mitigation strategy if the application is running on 5.1.x or lower . For iOS6 and above, use the recommended tools.

While it has always been the case that you should not disassemble the receipt directly, the discovered vulnerability put Apple between the stone and the difficult place in how to solve this problem, and decided that application developers were implementing the verification. This means that when the user updates the application, receipts are now protected again (regardless of the version of iOS), thereby providing better coverage for corrections. As a side effect, this means you need to give up on how you should do it (but Apple gives you permission to do so).

I agree that the documentation is not entirely clear and can be clarified a little more (you should give them feedback on the documentation pages below). Apple has published a mitigation strategy, and they state that it should be used on iOS 5.1.x and lower to eliminate this vulnerability. Responsibility for them depends if they change the format / content of IAP revenues.

+3
source

Apple currently also recommends validation validation on the device. See Verifying receipts locally and WWDC 2013 talk. Using receipts to protect your digital sales .

0
source

Source: https://habr.com/ru/post/1494473/


All Articles