32

Android でアプリ内製品を販売するためのトレーニング クラスでは、購入リクエストを行うときにペイロードを使用することを提案しています。

5 番目の引数には、注文に関する補足情報を送信するために使用できる「開発者ペイロード」文字列が含まれます (空の文字列の場合もあります)。通常、これは、この購入リクエストを一意に識別する文字列トークンを渡すために使用されます。文字列値を指定すると、Google Play は購入応答とともにこの文字列を返します。その後、この購入についてクエリを実行すると、Google Play はこの文字列を購入の詳細と共に返します。

セキュリティに関する推奨事項:アプリケーションが購入を行ったユーザーを識別するのに役立つ文字列を渡すことをお勧めします。これにより、後でそのユーザーによる正当な購入であることを確認できます。消耗品の場合はランダムに生成された文字列を使用できますが、非消耗品の場合はユーザーを一意に識別する文字列を使用する必要があります。

IAB 購入ページの実装にも同様の推奨事項があり、独自の安全なサーバーでペイロード値を確認する必要があるという追加の提案があります。

セキュリティに関する推奨事項:購入リクエストを送信するときは、この購入リクエストを一意に識別する文字列トークンを作成し、このトークンを developerPayload に含めます。ランダムに生成された文字列をトークンとして使用できます。Google Play から購入応答を受け取ったら、返されたデータの署名、orderId、developerPayload 文字列を確認してください。セキュリティを強化するために、独自の安全なサーバーでチェックを実行する必要があります。orderId が以前に処理したことのない一意の値であること、および developerPayload 文字列が以前に購入要求で送信したトークンと一致していることを確認してください。

Google が API のデモンストレーションに使用している Trivial Drive アプリのソース コードを見ると、次の警告が表示されます。

* WARNING: Locally generating a random string when starting a purchase and
* verifying it here might seem like a good approach, but this will fail in the
* case where the user purchases an item on one device and then uses your app on
* a different device, because on the other device you will not have access to the
* random string you originally generated.
*
* So a good developer payload has these characteristics:
*
* 1. If two different users purchase an item, the payload is different between them,
*    so that one user's purchase can't be replayed to another user.
*
* 2. The payload must be such that you can verify it even when the app wasn't the
*    one who initiated the purchase flow (so that items purchased by the user on
*    one device work on other devices owned by the user).
*
* Using your own server to store and verify developer payloads across app
* installations is recommended.

したがって、これらすべてのメッセージから、ペイロードに乱数/文字列を使用するのは悪い考えのように思えます。また、最後の警告を読んだ後、デバイス ID をペイロードとして渡すのは悪い考えのように思えます。デバイスが異なると同じユーザーでも異なるためです。では、開発者のペイロードには何を使用すればよいでしょうか?

私のアプリは、サービスにサインインしなくてもユーザーがアクセスできるローカル機能を提供します。したがって、「ユーザー」の概念はなく、サーバー側のコンポーネントもありません。アプリ内購入リクエストは、アプリから広告を削除するアップグレード用です。このようなアプリでペイロード機能を利用することは理にかなっていますか?それとも空の文字列を使用してリプレイ攻撃を受けやすいままにしておく方がよいでしょうか?

4

1 に答える 1

15

InApp 購入に関する私の知識は、古い v2 ライブラリからのものです。私は最新の v3 を使用していません。しかし、うまくいけば、私はまだ役に立ちます。

はい、開発者のペイロードを追加のセキュリティ機能として使用することは間違いなく役立ちますが、使用するかどうかはおそらく客観的なジレンマよりも主観的なものです. 私の場合、顧客はアプリ内購入後に 200 MB のファイルをダウンロードする必要があるため、クライアントには既にサーバーが混在していました。開発者ペイロードを使用して、ダウンロードが承認されたファイルに関する情報を保存しました。この情報は、ダウンロードしたファイルの処理方法をアプリに伝える上で重要でした。

verifyPurchase()サーバー呼び出しでローカル メソッドをオーバーライドすることで、セキュリティを強化しました。IE、チェックする独自のナンスを提供します。ローカルで行うことはあまり安全ではありません。

あなたの状況については、リスクとコストの問題だと思います。アプリがハッキングされ、顧客が購入を迂回するリスクと、追加のセキュリティを実装するためのコストはどのようなものですか。アプリが 100,000 回以上ダウンロードされている場合、かなりのリスクがあります。100 万回を超える場合は、リスクが高くなります。ほんの数千の場合、著作権侵害はおそらくあなたのアプリを見落とします. 追加のセキュリティを選択した場合は、サーバーを起動して実行する必要があります。次に、アプリとサーバーに必要なすべてのコードとハンドシェイクを追加します。いずれも時間とお金がかかります。特に、アプリの存続期間中にサーバーの料金を支払う場合。

于 2013-04-06T13:59:34.347 に答える