2

AppleのVerificationController.mの例を実装した場合でも、サーバー側のレシート検証を行う必要がありますか？また、サーバー側を行う場合は、デバイスからAppleのサーバーに接続していないため、VerificationController.mを実装する理由はないようです。

最良の場合、自分のhttpsサーバーを実行するための優れた方法がないため、VerificationController.mのみを実装したいと思います。それで十分？アプリはiOS5以降で動作します

4

1 に答える 1

3

これは見た目よりもややこしいので、おそらく微妙に間違っていると思いますが、次のようになります。

元の攻撃は、iOS ≤ 5.x の 2 つの弱点に依存しています。

  • App Store サーバーが本物であることを確認できません (ユーザー/攻撃者が CA 証明書のインストールを許可され、SSL 証明書の確認を回避します)。
  • 領収書がそのデバイスに対して有効であることを確認できませんでした。

これにより、ユーザー/攻撃者は App Store サーバーになりすまして、他人の購入に対する有効な領収書を提示することができます。

VerificationController は最初の弱点を修正できません (StoreKit が Apple と通信する方法を変更できません)。ほとんどの場合、2番目を修正するだけです。また、必要以上に多くのことをチェックしているように見えます (ただし、ここでは明らかに間違っている可能性があります)。これには、おそらく StoreKit が既にチェックしている一連のものが含まれます。

クライアント側の検証では、誰かがクライアントをハッキングするのを防ぐことはできません。これは、ジェイルブレイクされた電話では非常に簡単です. 購入したものが同じように簡単にハッキングされる可能性がある場合 (ゲームの弾薬/広告をオフにするなど)、これは実際には問題ではありません。

サーバーが購入するものを提供する場合は、サーバー側の検証が望ましいです (DLC/Skype クレジット/FarmCoins など)。

  • 消耗品の場合、サーバーはトランザクションが 1 つのアカウントにのみ適用されるようにする必要があります。デバイス ID の確認は少し余分です — 攻撃者は、購入者が領収書を渡す前にトランザクションの領収書を送信する必要があります (実際には攻撃ではありません)、攻撃者は SSL への攻撃で領収書を盗みます (これは心配するよりもはるかに大きなことを意味します）。
  • 非消耗品 (DLC など) の場合は、デバイス ID も確認する必要があります。これは、クライアントがデバイス ID をサーバーに送信するのと同じくらい簡単な場合があります。これは、ハッキングされたクライアントから保護されませんが、攻撃者はデバイス ID を偽造したり、DLC を海賊版にしたりすることができます.

通常、領収書を購入した商品に変換する時点で検証を行います。

ただし、VerificationController にはいくつかの問題があります。

  • 受信確認サーバーが EV 証明書を使用していることを確認しますが、他の SSL 層の確認は行いません。ユーザーが EV 対応の CA 証明書をインストールできるかどうかはわかりません (そして、EV CA が侵害されるまでそう長くはかかりません)。
  • 受信確認パスワードをアプリに埋め込む必要があります (「パスワード」と「ITC_CONTENT_PROVIDER_SHARED_SECRET」を検索してください)。脱獄した電話で抽出するのは簡単です。攻撃者がこれをどのような悪用に使用できるかはわかりませんが、シークレットのポイントは、それがシークレットであるということです!
  • 「前に見た」トランザクションは無効と見なされますが、受信確認サーバーに接続する前に「見た」トランザクションとしてマークします。これは、受信確認接続が失敗した場合に到達しないことを意味します。これは//Validation suceeded. Unlock content here.、貧弱な 3G 接続で簡単に発生する可能性があります. これは、非消費型トランザクション (復元されたトランザクションは新しいトランザクション ID を取得すると思います) では問題にならないかもしれませんが、消費型は永久に失われることを意味します。-[SKPaymentQueue finishTransaction:]受信確認が成功するまで呼び出しを延期できますが、これにより未完了のトランザクションがキューに残されます。ユーザーに請求することなく最終的に期限切れになることを願っています。
  • NSUserDefaults の内容を信頼します。これはアプリのバックアップの一部であり、簡単に編集できます。
  • -connection:didReceiveData:がすべての応答データを返すことを前提としています。これは、サーバーと NSURLConnection の実装の詳細に当てはまる場合がありますが、これに依存するのは賢明ではありません。
于 2013-01-18T22:24:11.000 に答える