78

アプリ内課金APIのバージョン3を使用しています。私は単一の管理された非消耗品を持っています。この機能はまだアプリでリリースしていないので、購入する前に購入ペイロードの内容を決定したいと思います。

「セキュリティのベストプラクティス」から：

購入リクエストを行うときに開発者のペイロード文字列を設定します

アプリ内課金バージョン3APIを使用すると、購入リクエストをGooglePlayに送信するときに「デベロッパーペイロード」文字列トークンを含めることができます。通常、これは、この購入要求を一意に識別する文字列トークンを渡すために使用されます。文字列値を指定すると、GooglePlayはこの文字列を購入応答とともに返します。その後、この購入についてクエリを実行すると、GooglePlayはこの文字列を購入の詳細とともに返します。

アプリケーションが購入を行ったユーザーを識別するのに役立つ文字列トークンを渡す必要があります。これにより、後でこれがそのユーザーによる正当な購入であることを確認できます。消耗品の場合はランダムに生成された文字列を使用できますが、非消耗品の場合はユーザーを一意に識別する文字列を使用する必要があります。

Google Playから応答が返ってきたら、デベロッパーのペイロード文字列が購入リクエストで以前に送信したトークンと一致することを確認してください。さらなるセキュリティ対策として、自分の安全なサーバーで検証を実行する必要があります。

正誤を問わず、購入確認を行うサーバーを設置するという「さらなるセキュリティ対策」を講じないことにしました。そして、私は購入の自分の記録を保存しません-私は常に課金APIを呼び出します。それで、私がこのペイロード検証を行う理由は本当にありますか？検証API自体は、購入したアイテムを報告する前にユーザーのIDを確実に検証します。攻撃者がデバイス（アプリまたはGoogle Play APIのいずれか）を侵害した場合、追加のチェックを行うメリットはありません。簡単に回避できるデバイス上のユーザーのID。それとも、私が考えていないのにこれを行う理由はありますか？

4

8 に答える 8

30

アプリケーションが購入したユーザーを識別するのに役立つ文字列トークンを渡す必要があります...

アプリケーションが独自のユーザー ログインと ID を提供し、電話が接続されている Google アカウントとは異なる場合は、開発者ペイロードを使用して、購入を行ったアカウントの 1 つに購入を関連付ける必要があります。そうしないと、誰かがあなたのアプリでアカウントを切り替えて、購入したものを利用する可能性があります。

例えば

アプリに userA と userB のログインがあるとします。また、携帯電話の Android の Google アカウントは X です。

  1. userA がアプリにログインし、ライフ メンバーシップを購入します。購入の詳細は Google アカウント X に保存されます。
  2. userA がログアウトし、userB がアプリにログインします。これで、android の Google アカウントがまだ X であるため、userB も生涯メンバーシップの特典を利用できます。

このような悪用を避けるために、購入をアカウントに関連付けます。上記の例では、userA が購入を行っているときに、開発者ペイロードを「userA」として設定します。そのため、userB がサインインすると、ペイロードはサインインしたユーザー (userB) と一致しないため、購入は無視されます。したがって、userB は、userA が行った購入の特典を得ることができません。

于 2013-05-04T06:37:17.263 に答える
21

開発者のペイロード処理には別のアプローチもあります。Nikolay Elenkov が言ったように、ユーザー ID を要求し、アプリにユーザー プロファイルの追加のアクセス許可を設定するのはオーバーヘッドが大きすぎるため、これは良いアプローチではありません。それでは、アプリ内課金 v3 サンプルの TrivialDrive サンプル アプリの最新バージョンで Google が何を言っているか見てみましょう。

  • 警告: 購入を開始するときにローカルでランダムな文字列を生成し、ここで検証するのは良い方法のように思えるかもしれませんが、ユーザーがあるデバイスでアイテムを購入し、別のデバイスでアプリを使用する場合、これは失敗します。他のデバイスでは、最初に生成したランダムな文字列にアクセスできなくなります。

したがって、購入したアイテムを別のデバイスで検証する場合、ランダムな文字列はお勧めできませんが、それでも、購入応答を確認するのにこれが良い考えではないとは言いません。私は言うでしょう-ランダムな一意の文字列を送信して購入を確認するためだけに開発者ペイロードを使用し、それを設定/データベースに保存し、購入応答でこの開発者ペイロードを確認します。アクティビティ開始時のインベントリ (アプリ内購入) のクエリについては、ランダムな一意の文字列が保存されていない別のデバイスで発生する可能性があるため、開発者のペイロードをチェックする必要はありません。それが私がそれを見る方法です。

于 2013-03-26T15:38:05.130 に答える
16

をどのように確認するかによって異なりますdeveloperPayload。リモート検証 (サーバーを使用) とローカル (デバイス上) の 2 つのシナリオがあります。

サーバ

検証にサーバーを使用している場合はdeveloperPayload、デバイスとサーバーの両方で簡単に計算できる任意の文字列にすることができます。リクエストを実行したユーザーを特定できるはずです。すべてのユーザーが対応する を持っていると仮定するとaccountId、は次のように (SKU 名)developerPayloadと組み合わせて計算できます。purchaseId

MD5(purchaseId + accountId)


デバイス

developerPayload user email であってはなりません。メールをペイロードとして使用すべきではない理由の良い例は、Google for Work サービスです。ユーザーは、アカウントに関連付けられている電子メールを変更できます。唯一の定数はaccountId. ほとんどの場合、電子メールは問題ありません (たとえば、現時点では Gmail アドレスは不変です) が、将来に備えて設計することを忘れないでください。

複数のユーザーが同じデバイスを使用する可能性があるため、アイテムの所有者を区別できる必要があります。デバイス検証developerPayloadの場合、ユーザーを一意に識別する文字列です。例:

MD5(purchaseId + accountId)


結論

一般にdeveloperPayload、どちらの場合も は だけである可能性がありますaccountId。私にとっては、あいまいさによるセキュリティのように見えます。MD5 (またはその他のハッシュ アルゴリズム)purchaseIdは、アカウントの ID を使用していることを明示的に示すことなく、ペイロードをよりランダムにする方法にすぎません。攻撃者はアプリを逆コンパイルして、計算方法を確認する必要があります。アプリが難読化されている場合は、さらに効果的です。

ペイロードはセキュリティを提供しません。これは、「デバイス」アプローチを使用して簡単にスプーフィングでき、「サーバー」チェックに労力を費やす必要はありません。Google パブリッシャー アカウント コンソールで利用できる公開鍵を使用して署名チェックを実装することを忘れないでください。

*電子メールの代わりにアカウント ID を使用することに関する必読のブログ投稿。

于 2014-12-01T10:45:14.720 に答える
5

自明なドライブ サンプルの作成者自身によって提供された IAB v3 に関する Google IO ビデオでは、これはビデオの最後で簡単に説明されています。これはリプレイ攻撃を防ぐためです。たとえば、攻撃者がトラフィックを盗聴し、成功した購入を含むパケットを盗み、自分のデバイスでパケットをリプレイしようとします。アプリがプレミアム コンテンツをリリースする前に (理想的にはサーバーから) dev ペイロード (理想的にはサーバー上) を介して購入者の身元を確認しない場合、攻撃者は成功します。パケットが無傷であるため、署名検証ではこれを検出できません。

私の意見では、この保護は、クラッシュ オブ クランのようなオンライン アカウント接続を備えたアプリ (とにかくユーザーを特定する必要があるため、ペイロードは自然に発生します) に最適であると思われます。 . 対照的に、apk に対するクライアント側のハッキングが既にプレミアム コンテンツのロックを解除できる場合、この保護はあまり役に立ちません。

(攻撃者がペイロードのスプーフィングを試みた場合、署名の検証は失敗するはずです)。

于 2016-03-16T07:46:20.127 に答える
3

私はこれに苦労しました。Google Play アカウントは「管理された」アイテムを 1 つしか所有できませんが、複数のデバイス (私は 3 つ持っています) を持つことができるため、「デバイスごと」に販売しているという誰かからの上記のコメントは機能しません...彼らはプレミアム アップグレードを購入すると、すべての携帯電話/タブレットで動作するはずです。

ユーザーの電子メールアドレスを取得するという考えは大嫌いですが、他に信頼できる方法は見つかりませんでした。そのため、アカウント リストで「google.com」に一致する最初のアカウントを取得し (マニフェストに追加する許可)、すぐにそれをハッシュして、電子メール アドレスとして使用できなくなりますが、「十分に一意な」 "トークン。それが開発者ペイロードとして送信するものです。ほとんどの人は自分のデバイスを Google Play ID でアクティベートするため、3 つのデバイスすべてが同じトークンを取得する可能性があります (各デバイスで同じハッシュ アルゴリズムを使用)。

複数の「ユーザー」がいるキットカットでも動作します。(私の開発者 ID はあるユーザーにあり、テスト ID は別のユーザーにあり、各ユーザーはそれぞれのサンドボックスにあります)。

合計 3 人のユーザーを使用して 6 つのデバイスでテストしましたが、各ユーザーのデバイスは同じハッシュを返し、異なるユーザーはすべて異なるハッシュを持ち、ガイドラインを満たしています。

ユーザーの電子メール アドレスを保存することはありません。アカウント名を取得するコードからハッシュ関数に直接渡され、ハッシュのみがヒープに保存されます。

ユーザーのプライバシーをさらに尊重するより良い解決策が他にあるかもしれませんが、今のところ見つけられていません。アプリが公開されたら、プライバシー ポリシーでユーザーのメール アドレスをどのように使用するかについて非常に明確に説明します。

于 2014-03-06T04:11:11.337 に答える