※この話題は iOS5.1以前が対象
攻撃の方法はDNSのレコードを変更してAppStoreのサーバーに対する
リクエストを偽装サーバーにリダイレクトし、偽装サーバーがAppStoreのサーバーの
エミュレーションを行うことで支払ったかのように見せることができる、というものの
ようですね。
なるほど。昨日紹介したライブラリ CargoBay がiTSの証明書確認までやっていた理由がこれでわかった。
Blocksベースの高機能な StoreKit ラッパー - CargoBay | Cocoaの日々情報局
確かに接続先が偽装された場合を想定すると証明書の確認が必要になる。
Appleは昨年7月に安全なアプリ内課金に関する指針と支援コードの提供を行っていた。
対象は iOS5.1以前。
チェック指針は４つ
Check that the SSL certificate used to connect to the App Store server is an EV certificate.
Check that the information returned from validation matches the information in the SKPayment object.
Check that the receipt has a valid signature.
Check that new transactions have a unique transaction ID.
またこのサイトで VerificationController.h/m が配布されている。
ヘッダの内容：
#define IS_IOS6_AWARE (__IPHONE_OS_VERSION_MAX_ALLOWED > __IPHONE_5_1)
#define ITMS_PROD_VERIFY_RECEIPT_URL @"https://buy.itunes.apple.com/verifyReceipt"
#define ITMS_SANDBOX_VERIFY_RECEIPT_URL @"https://sandbox.itunes.apple.com/verifyReceipt";
#define KNOWN_TRANSACTIONS_KEY @"knownIAPTransactions"
#define ITC_CONTENT_PROVIDER_SHARED_SECRET @"your secret here"
char* base64_encode(const void* buf, size_t size);
void * base64_decode(const char* s, size_t * data_len);
@interface VerificationController : NSObject {
NSMutableDictionary *transactionsReceiptStorageDictionary;
}
+ (VerificationController *) sharedInstance;
// Checking the results of this is not enough.
// The final verification happens in the connection:didReceiveData: callback within
// this class. So ensure IAP feaures are unlocked from there.
- (BOOL)verifyPurchase:(SKPaymentTransaction *)transaction;
実装をコードを読むと...見覚えがある。ああ、CargoBay で見たのはこのコードだ。CargoBayはこのコードを元に証明書チェック他の処理を組み込んでいたのか。
- - - -
攻撃自体が恐らく少ない上に iOS6では改善されているとのことなので実際にはここまでやる必要は無いと思われる。