web-dev-qa-db-ja.com

Google IAPは確認のために短い購入トークンを返します

サーバー側の検証Google IAP購入トークンを実装しました。私のモバイルアプリは、Googleから取得するときにこのトークンを私に送信します。

通常のトークンは次のようになります

minodojglppganfbiedlabed.AO-J1OyNtpooSraUdtKlZ_9gYs0o20ZF_0ryTNACmvaaaG5EwPX0hPruUdGbE3XejoXYCYzJA2xjjAxrDLFhmu9WC4fvTDNL-RDXCWjlHKpzLOigxCr1QhScXR8uXtX8R94iV6MmMHqD

しかし時々私はこのような短いトークンを取得します

korpimulxmslxissnschtkdb

Google Play Developer APIを介してこのトークンを確認する場合： https://www.googleapis.com/androidpublisher/v2/applications/packageName/purchases/subscriptions/subscriptionId/tokens/token 、短いトークンの場合404エラーが発生します。

問題はどこだ？この短いトークンが実際のトランザクションを表す可能性はありますか？

androidin-app-purchasegoogle-playin-app-billing
32
cermakjn

私はしばらくの間、理由がわからずにアプリで同じ無効なトークンを受け取っています。トークンは、24文字のアルファベット（例：glvnqnpjqslcagyimgxeuybk）、15桁（例：781871156762279、 この質問を参照 ）、および有効なものとは少し異なる形式の適切な長さのトークン（例：xdavcuvdnniwwrhwemleqjdz.rSQozm...この質問を参照 ）。

これらは、これらのさまざまなトークンについて アプリ内課金API から一度に受け取ったエラーメッセージです。

  • "code": 404, "message": "The purchase token was not found."
  • "code": 400, "message": "Invalid Value"
  • "code": 400, "message": "Your request is invalid for this subscription purchase."

答え マーク・グリーンストックから与えられたものは、問題を再現しようとするアイデアを私に与えました。

不正な購入

アプリ内購入をハッキングすると主張する2つのアプリをテストしました：Freedom、およびLucky Patcher、ルート化されたデバイス上。前者は機能しませんでした。私たちのアプリが購入できることが検出されましたが、偽のアプリを作成しようとしたときに、「このアプリの購入は偽造できない」と通知されました。後者のdidは、いじくり回した後で機能し、質問とまったく同じように短い購入トークンを生成しました。 アプリ内課金API を介してトークンを確認しようとすると、以前とまったく同じ「無効なトークン」メッセージが表示されました。

このメソッド を使用して、無効なトークンを生成するデバイスのルートステータスのログ記録も開始しました。これは何の証拠にもなりませんが、ほぼすべての無効なトークンがルート権限を取得されたデバイスから発信されたという事実は、不正行為の疑いを抱かせました。

攻撃

攻撃は次のように機能すると思います。これについてもっと知っている人はチャイムしてください！

  • ユーザーは、ルート化されたデバイスに無料のアプリ内購入を行うと主張するハッキングアプリの1つをインストールします
  • ハッキングアプリは、デバイス上の正当なアプリ内課金サービスにパッチを適用するか、デバイスをエミュレートします
  • 購入フローの間に、ハッキングアプリが正規のサービス向けの purchase Intent を傍受します
  • ハッキングアプリは購入リクエストを処理し、正当なサービスと同じ方法でレスポンスを生成しますが、購入リクエストはGoogleのサーバーに到達しません
  • localトークン検証に依存するアプリは、アプリ内課金サービスからの購入をリクエストします。このリクエストは、購入が有効であると主張するハッキングアプリによっても傍受されます
  • serverトークン検証に依存するアプリは、購入トークンをサーバーに送信し、サーバーは アプリ内課金API を呼び出します。トークンを見たので、「無効なトークン」応答を返します

緩和

  • アプリ内課金サービスに完全に依存しているアプリは脆弱です！ purchaseおよびpurchase validationリクエストは、どちらも同じ不正なアプリによって傍受されます。防御はありません。
  • サーバーバックエンドに依存するアプリは、購入トークンをバックエンドに送信して、発行元APIを通じて確認する必要があります。これらのアプリは、バックエンドがそれを確認して肯定的な結果をアプリに返すまで、ユーザーに購入のクレジットをしない必要があります。アプリ内課金の場合、バックエンドはおそらく セキュリティの推奨事項 に従う必要があります。これらのアプリは、不正な購入から安全ですが、無効な購入が多数発生します。
  • トークンの長さや形式、注文ID、または購入の有効性を判断するための他のデータに依存することは安全ではないと私は思います。これらのトークンは、以前の形式をエミュレートしていたため、おそらく不正な形式です。おそらく、ハッキングアプリの作成者は、Googleが考案したフォーマットをエミュレートするバージョンを最終的にリリースするでしょう。安全な唯一の方法は、ユーザーが制御するデバイスでアプリ内課金APIを介して購入を確認することです。サーバー。
40
savanto

あなたはこれを解決したのですか？

私が提案できる唯一の理由は、ルート化されたデバイスにインストールできる「Android向けのFreedomアプリ内購入」アプリのようなアプリ内購入クラッカーによってトークンが生成されたことです。

自分で行ったテスト購入の短いトークンを受け取ったかどうかを確認したいと思います。

トークンが偽物であることを示すもう1つの兆候は、アプリでの購入後に取得するorderIdの形式です。

Administing In-app Billing docsに示されている形式に従っていない場合、それはおそらく不正な購入です。

3
Marc Greenstock

一部の偽のIAPプロバイダーで機能する部分的な軽減策を見つけました：デジタル署名を手動で再確認します。IAPシミュレーターが行うことは何でも、それらは行いませんGoogleの秘密RSAキーのコピーを持っている。私は自分の署名チェックをロールバックしましたが、少なくともいくつかの偽のトランザクションをキャッチします。

チェックコードは要旨です

0
Seva Alekseyev