web-dev-qa-db-ja.com

APIアクセスをモバイルアプリのみに制限するために提案された方法

Public REST APIをモバイルアプリケーションのみに制限することはできないことをたくさん読みましたが、私にはアイデアがあり、それについて意見を求めています：

可変アプリキーメソッド

モバイルアプリ

  1. 現在の接続のIPアドレスを取得する
  2. シークレットアルゴリズムを使用して、IPアドレスからハッシュされたAppKeyを生成します。
  3. 各APIリクエストでAppKeyを送信します

サーバー側

  1. 着信要求のIPアドレスを確認する
  2. 同じ秘密アルゴリズムを使用して、そのIPアドレスからAuthKeyを生成します。
  3. AuthKeyとAppKeyを比較し、一致する場合、アプリケーションだけが秘密のアルゴリズムを知っているため、アプリケーションがあなたと通信していることがわかります。

IPアドレスが変更された場合：

  • モバイルアプリで、新しいIPアドレスを使用してAppKeyを再生成します
  • サーバー側はリクエストのIPアドレスに依存するため、常に同じキーを生成します

これの主な利点は、AppKeyが常に変化することです。これは、コード内の1つのアプリケーションキーをハードコーディングするよりも優れており、リクエストヘッダーを読み取ることで簡単に盗まれる可能性があります。また、ユーザーからAppKeyを盗んだ場合でも、そのキーが生成されたのと同じIPアドレスを使用している必要があります。

何かご意見は？

結論：

正しいIPアドレスを返すには外部APIを呼び出す必要があるため、IPアドレスに依存することには問題があり、IPアドレスは常に変更されるため、すべてのリクエストの前にそれを行う必要があります。

2番目の問題は、モバイルでのインターネット接続がWiFiから3Gから4Gに大きく切り替わり、アプリケーションの動作が不安定になることです。

restapisecurityandroidmobile
1
DeepBlue

IPアドレスに基づいてダイナミックアクセスキーを生成すると保護が向上することは確かですが、このアプローチには多くの問題があります。

  1. モバイルデバイスのIPアドレスが非常に安定していると実際に想定することはできません。これは、IPアドレスが変更され、要求が拒否される可能性があることを意味します。さらに、APIを介して別のサービスにクエリを実行して、デバイスのパブリック側のIPアドレスが存在することを確認する必要もあります（NATの背後にある可能性があるため、わかりません）。特定の最新のモバイルネットワークでは、複数のIPアドレスに対応するリクエストの負荷を分散できます。つまり、リクエストごとに異なる外部IPを取得する場合があります。

  2. キーを計算するアルゴリズムは、アプリからリバースエンジニアリングして悪用することができます。ですから、それがいかに十分に保護されているかについて心配する必要があります。

  3. おそらく最も重要なことですが、これは実際には同じIPアドレスからの悪用を保護するものではありません（NATの背後にある同じネットワーク上のデバイスなど）。攻撃者は、中間者攻撃によって適切なAppKeyをキャプチャするだけで、同じIPアドレスから必要なスクリプトやその他のアプリを使用できます。

私の意見では、より良いアプローチは、アプリにシークレットを埋め込むことです。このシークレットをHMACの計算で使用し、APIリクエストパラメーターとともに使用して、リクエストがアプリからのものであることを示すことができます。もちろん、この秘密がアプリからリバースエンジニアリングされる可能性は依然としてあります。次に、それを防止するために使用できる一連のさまざまな保護策があります。

私はこの分野に特化した会社で働いています-モバイルアプリで使用されるバックエンドAPIを保護して、公式アプリでのみ使用できるようにしています。要求をスプーフィングすることによってマウントできるビジネス攻撃のタイプと、そのような攻撃をマウントするために一部の攻撃者が利用する長さに驚くでしょう。アプリに適用できるさまざまなレベルの保護について、非常に詳細なブログシリーズをご紹介します。役立つと思います https://www.approov.io/blog/practical -api-protection-walkthrough-part-1.html

3
Richard Taylor

いくつかのコメント

  1. あなたのメカニズムは、アルゴリズムの秘密性、つまり obcursityによるセキュリティ と呼ばれる手法に依存しています。これは、ほぼ普遍的に 悪い考え と見なされています。

  2. 特にインターネットで入手可能な 多種多様な解読器 を考慮すると、リバースエンジニアリングを防止するのに十分なほどコードを難読化できない可能性があります。

  3. ハッカーがコードを難読化できない場合でも、偽造されたネットワーク環境でアプリを実行し（IPアドレスを好きなように設定できる）、アプリを使用してキーハッシュを生成し、それらをリプレイ攻撃で使用します。

  4. アプリは可視IPアドレスを認識していない可能性が高く、サービスはアプリのローカルIPアドレスを認識していない可能性が高いため、一致させることが困難です。アプリはリクエストの一部としてローカルIPアドレスを通過する可能性がありますが、変更するのは簡単なため、当然、セキュリティメカニズム全体が無効になります。

  5. 安全なメカニズムに到達したとしても、ハッカーがアプリを使用したり、自分のコードを実行するためにアプリの一部を変更したりすることを妨げるものはありません。

  6. 一般に、 独自のセキュリティをロールする を行うのは非常に悪い考えです。

編集：

  1. 多分あなたのメカニズムはそれをハックしようとする最初のハッカーを遅くするでしょう。しかし、必要なのは、1人の男がそれを理解し、ハッカーページにクラックをアップロードすることだけです。その後、それはゲームオーバーであり、あなたの緩和策は価値がありません。

  2. ユーザーごとにキーを発行するわけではないため、侵害されたキーをブラックリストに登録したりブロックしたりすることはできません。ブロックできるのは全員または誰もいません。これにより、ユーザーごとにキーを発行する標準的なパターンよりもメカニズムが大幅に悪化します。

5
John Wu

簡単に言うと、特に後者が前者のように偽装しようとする場合、1つの未知のデバイスを別の未知のデバイスから区別することはできません。

標準的な方法は、デバイスごとのキーを生成することです。ユーザーにアプリを初期ワークフローの一部として登録させ、何らかの形でユーザーまたはデバイスのIDにリンクさせます。

これで、各API接続に一意のキーがあります。その使用を抑制でき（顧客間でより均等にAPIアクセスを共有するため）、haxx0rフォーラムをクロールして、そこで見つかったキーを禁止できます。

ただし、「モバイル」と「デスクトップ」を本当にうまく区別することはできません。スマートフォンは有線ネットワーク「モバイル」へのWi-Fi接続を介して機能していますか？もしそうなら、タブレット/ラップトップ/デスクトップ/サーバーが同じことをするのとどう違うのですか？そうでない場合、彼が「モバイルアクセスを使用していない」ことをモバイルアプリのユーザーにどのように説明しますか？

2
9000