安全なアプリ内課金 (iOS5.1以前）

※この話題は iOS5.1以前が対象

iOSのアプリ内課金における課金回避ハック、Mac向けアプリでも同種の穴が見つかる | スラッシュドット・ジャパン アップル

引用：

攻撃の方法はDNSのレコードを変更してAppStoreのサーバーに対する
リクエストを偽装サーバーにリダイレクトし、偽装サーバーがAppStoreのサーバーの
エミュレーションを行うことで支払ったかのように見せることができる、というものの
ようですね。

なるほど。昨日紹介したライブラリ CargoBay がiTSの証明書確認までやっていた理由がこれでわかった。
Blocksベースの高機能な StoreKit ラッパー - CargoBay | Cocoaの日々情報局

確かに接続先が偽装された場合を想定すると証明書の確認が必要になる。

Appleは昨年7月に安全なアプリ内課金に関する指針と支援コードの提供を行っていた。

In-App Purchase Receipt Validation on iOS

対象は 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では改善されているとのことなので実際にはここまでやる必要は無いと思われる。