5

ここでアプリ内購入用のAppleの検証コントローラーパッチを調べていました：https://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_ReceiptValidation/_index.html

サーバー検証を実装する予定でしたが、すぐに応答する必要はありません。

新しいコードの非同期部分は絶対に必要ですか。単純なサーバー側の検証よりも利点がありますか?

即時の解析とチェックを使用して利益を得ることができれば、それは素晴らしいことです。

ありがとう！

編集:この質問は、コードがないと少し空っぽに感じます:

具体的には、メインの verifyPurchase 関数を次のもののみを含むように変更することについて話している:

- (BOOL)verifyPurchase:(SKPaymentTransaction *)transaction;
{
    return [self isTransactionAndItsReceiptValid:transaction];
}

...そしてクライアントを取り除きます->サーバーポスト。最近のハッキングに対する脆弱性は残りますか?

4

1 に答える 1

3

コードを見た後、あなたの質問はより理にかなっています。

問題の攻撃は、誰かが他の誰かの有効な領収書を提示することです。デバイス/購入者に関連付ける領収書データには何もないようです。購入日を確認することで、これをある程度軽減できます (ただし、ユーザーの管理下にある正確な時刻がデバイスにある場合のみ)。

(クライアントがレシートと一致する必要がある 256 ビットのランダムな nonce を生成した場合、この攻撃は機能しません。明らかに、攻撃者はバイナリ/PRNG をハッキングできますが、どちらの場合も、既に失われています。)

ちなみに、コードには多くの問題があります。

  • サーバー証明書の唯一のチェックは、それが EV 証明書であることです。攻撃者は CA を完全に制御できるため、これは簡単に偽造できるはずです。
  • -isTransactionAndItsReceiptValid:トランザクション ID は、ネットワーク チェックが完了する前に「既に確認された」トランザクションのリストに永続的に追加されますが、コンテンツはネットワークが戻った後にのみロック解除されます。接続が失敗した場合、領収書を再検証することはできません。そのため、ユーザーのお金は実質的にブラック ホールに消えてしまいます。
  • 検証しているのと同じデバイスでトランザクションが発生したと想定しています。
  • ITC_CONTENT_PROVIDER_SHARED_SECRET が実行可能ファイルに埋め込まれていることを想定しています (ジェイルブレイクされたデバイスで復号化するのは簡単です)。
  • -connection:didReceiveData:が完全なレシート データを返すことを前提としています (これは断片化のためそうではないかもしれませんが、Apple がサーバーの実装を制御しているため、おそらく保証できます)。
于 2012-07-25T13:17:25.323 に答える