このトピックを読む前に、これはトピックの続きなので、ブレーカーからアプリ内購入を保護する前の方法を読むことをお勧めします。
私のアプリケーションでは、確認後、領収書がサーバーに送信され、そこで分析してログに保存します。 付属のJSONは標準であり、何らかの修正が加えられていることに気付きました。
標準的なものは次のようになります。
{ "receipt": { "original_purchase_date_pst": "2012-06-08 04:13:04 America/Los_Angeles", "purchase_date_ms": "1339153984956", "original_transaction_id": "430000009214053", "original_purchase_date_ms": "1339153984956", "app_item_id": "12312312323", "transaction_id": "430000009214053", "quantity": "1", "bvrs": "1.0", "version_external_identifier": "7809437", "bid": "xx.yyyyyy.zzzzzzz", "product_id": "xx.yyyyyy.zzzzzz.uuuuuu", "purchase_date": "2012-06-08 11:13:04 Etc/GMT", "purchase_date_pst": "2012-06-08 04:13:04 America/Los_Angeles", "original_purchase_date": "2012-06-08 11:13:04 Etc/GMT", "item_id": "123123123" }, "status": 0 }
その結果、3種類のハッキングの試みに気付きました。
1.最も一般的なオプション。 クラッカーはAppleのサーバー応答を偽造しません。その結果、受信は次のようになります。
{ "status": 21002, "exception": "java.lang.ClassCastException" }
status = 21002であるため、以前の方法ではこのようなハッキングに対処していました。
2.最近、新しいハッキング方法が登場しました。 これがどのユーティリティで行われるのかはわかりませんが、2番目の要求に対するAppleサーバーの応答を偽装しています。
JSONは次のようになります。
{ "status":0 }
このようなハッキングは追跡が容易です。 「product_id」などのいくつかの変数の存在を確認でき、すべてが適切に配置されます。
3.しかし、それほど単純ではありません。 偽のJSONの別のバリアントが最近登場しました。
{ "status": 0, "receipt": { "product_id": "xx.yyyyyy.zzzzzzzz.uuuuuuu", "purchase_date": 1339152660.383128, "quantity": 1, "transaction_id": "xx.yyyyyy.zzzzzzzz.uuuuuuu" } }
何かをもう一度チェックする場合は、破壊プログラムがリクエストから取得できないものを見つける必要があります。 すべてのデータを確認した後、それを回避するための非常に簡単な方法があることを理解しました。
「item_id」を確認する必要があります-これは、Appleがアプリ内購入を含む各製品に割り当てるIDです。 「Manage In-App Purchases」ボタンをクリックして、iTunesConnectで視聴できます。
次に、コードは次のようになります。
kFeature1 = "xx.yyyyyy.zzzzzzzz.uuuuuuu"; kFeatureItemID1 = "123123123"; kFeature2 = "xx.yyyyyy.zzzzzzzz.uuuuuuu"; kFeatureItemID2 = "123123123"; kFeature3 = "xx.yyyyyy.zzzzzzzz.uuuuuuu"; kFeatureItemID3 = "123123123"; - (BOOL)verifyReceipt:(NSData*)receiptData { NSString *urlsting = @"https://buy.itunes.apple.com/verifyReceipt"; NSURL *url = [NSURL URLWithString:urlsting]; NSMutableURLRequest *theRequest = [NSMutableURLRequest requestWithURL:url]; NSString *st = [receiptData base64EncodedString]; NSString *json = [NSString stringWithFormat:@"{\"receipt-data\":\"%@\"}", st]; [theRequest setHTTPBody:[json dataUsingEncoding:NSUTF8StringEncoding]]; [theRequest setHTTPMethod:@"POST"]; [theRequest setValue:@"application/x-www-form-urlencoded" forHTTPHeaderField:@"Content-Type"]; NSString *length = [NSString stringWithFormat:@"%d", [json length]]; [theRequest setValue:length forHTTPHeaderField:@"Content-Length"]; NSHTTPURLResponse* urlResponse = nil; NSError *error = [[NSError alloc] init]; NSData *responseData = [NSURLConnection sendSynchronousRequest:theRequest returningResponse:&urlResponse error:&error]; NSString *responseString = [[NSString alloc] initWithData:responseData encoding:NSUTF8StringEncoding]; NSDictionary *dic = [responseString JSONValue]; NSInteger status = [[dic objectForKey:@"status"] intValue]; NSDictionary *receiptDic = [dic objectForKey:@"receipt"]; BOOL retVal = NO; if (status == 0 && receiptDic) { NSString *itemId = [receiptDic objectForKey:@"item_id"]; NSString *productId = [receiptDic objectForKey:@"product_id"]; if (productId && ([productId isEqualToString:kFeature1] || [productId isEqualToString:kFeature2] || [productId isEqualToString:kFeature3] )) { if (itemId && ( [itemId isEqualToString:kFeatureItemID1] || [itemId isEqualToString:kFeatureItemID2] || [itemId isEqualToString:kFeatureItemID3] )) { retVal = YES; } } } return retVal; }
このコードのプラス：クラッカーはitem_idの値を知らず、要求されたときにどこにも送信されません。 そのため、このような領収書を偽造するのは簡単ではありません。 おそらく、可能です。
そして、すべてが壊れる可能性があると言わないでください。 この保護の目的は、標準的な手段で大量のハッキングを防ぐことです。