iPhoneアプリのアプリ内課金を回避する方法と対策

アプリ内課金のアイテムを無料で使える方法を公開したハッカーが話題になっていたので、どんなものなのか、開発者側で対応する方法は無いのかを調べてみました。

手法については、いくつかのサイトで記事になっています。

ハッカーがAppStoreアプリ内課金に「タダで買える」穴発見！購入殺到でサーバーダウン（動画） – ギズモード・ジャパン

ハッカー、iPhoneアプリの課金コンテンツを無料でダウンロードする手法を発見 – タッチラボ

日本では法的にどのような対応になるのかは調べてませんが、安易に真似はしない方が良いのは確かだと思います。

設定手順としては、

１．iPhoneにハッカーが作った証明書を入れる。
２．iPhoneの無線LANの設定画面で、ハッカーが作ったDNSサイトを使うように設定する。
３．後は普通にアプリ内課金するだけ。

みたいな感じですが、やっている事としては、

・ハッカーのDNSサーバーを使う事で、Appleの課金決済サーバーへのリクエストをハッカーが用意したサーバーへ向けている。
・ハッカーのサーバーは購入に成功したかのようなレスポンスを返す。

ということでした。

手口を整理してみるとなるほどという感じですが、Appleも盲点だったのもかも知れません。

では開発者側で対応する方法は無いのかというと有ると思います。

まずアプリ内課金の種別ですが、以下の種類があります。

１．Consumable（消費型）
２．Non-Consumable（非消費型）
３．Auto-Renewable Subscriptions（自動更新の購読型）
４．Free Subscription（Newsstand向けの無料の購読型）
５．Non-Renewing Subscription（自動更新しない購読型）

例として分かりやすいのがNon-Consumableですが、Appleが課金情報を管理してくれて、ユーザーが再購入しようとしても購入済みですと表示してくれるので、シンプルな実装をするとすると、Appleの課金サーバーしか使わずに済みます。

Appleのドキュメントでも「組み込みプロダクトモデル」という方式で紹介されており、多くの開発者がやっているであろうことは、StoreKitでAppleへ課金を要求して、OKが返って来たらアイテムをアンロックするという処理だと思います。

この場合、Appleのサーバーに成り済まされると、アンロックできてしまいます。

ではどうするとこの手法に対抗できるかというと、課金したトランザクションに入っているレシート（SKPaymentTransactionのtransactionReceipt）の妥当性チェックをすることで対抗できます。

Googleで検索すると、transactionReceiptのチェック方法として、iPhone側でAppleの検証サーバーへレシートを送信してチェックするサンプルも出てきますが、この方法だと今回の手法に対しては無効です。

Appleへのリクエストがハッカーのサーバーへ振り分けられている以上、レシートの検証に対してもOKだというようなレスポンスを返しておけば使えてしまいます。

独自のサーバーを用意して、そこへレシートを送信し、独自のサーバーからアップルへリクエストして、妥当性をチェックする必要があります。

この方法でチェックする場合、独自のサーバーのドメインや、独自のサーバーとアプリ間のプロトコルは開発者次第なので、ハッカーのサーバーも対応しようとすると際限が無いというのと、独自のサーバーが見ているDNSを変えることは困難だと思うので、Appleのサーバーに成り済ますことも難しいです。

結果、レシートの妥当性チェックする独自サーバーを立てれば、今回の手口は防げると思います。

この手口が厄介だと思う所は、レシート検証用のASPサービスみたいな共通化されたものがポピュラーになってしまうと、そのサイトも成り済ましてしまえば使えるようにできてしまう訳で、レシート検証サーバーは多様性が無いとダメだというところです。

組み込みプロダクトモデルの手軽さは小規模デベロッパーに取っては魅力的な部分なので、Appleには何かしら対策を講じてもらいたい所ですね。

※iPhoneアプリ開発に関する投稿を今から始めるiPhoneアプリ開発にまとめました。