モバイルアクセス用のAPIの保護
私は、B2Bサービスとして他の会社（私たちのクライアント）が使用するNice REST/JSON APIを作成しました。各クライアントにはユーザー名とパスワードのペアがあり、HTTPSを実行して、サービスへのリクエストのソースIPを検証します。サービスの利用には費用がかかり、クライアントはサービスの利用に対して毎月請求されます。
現在、一部のクライアントは、ユーザー（B2C-エンドユーザー）に渡すモバイルアプリケーションを構築しています。私たちのサービスのこれらすべてのエンドユーザーがサーバーを持っているわけではなく、彼らはスマートフォンから直接サービスを使用したいと考えています（JSON/RESTは技術的に大したことではありません）。
問題は、サービスを詐欺から保護する方法がわからないことです。サードパーティの開発者がクライアントのモバイルアプリケーションの1つを分解し、ユーザー名/パスワード/セキュリティ認証情報をコピーして、アプリケーションでそれを使用するのを防ぐのは何ですか？これにより、彼はサービスを利用し、正当なクライアントの1人に使用料を請求することができます。
エンドユーザーがサーバーへの認証を要求されない限り、この問題に対する完全な暗号化ソリューションはないと確信しています。しかし、常にそうであるとは限りません。
最後の手段として、私はAndroid/IPhoneの難読化されたライブラリを配布できます。これは少なくともセキュリティの幻想を与えるでしょう...
編集（説明）：
シナリオを簡略化してみましょう。
- JSON REST APIを提供するハッキングできないWebサーバーがあります。
- モバイルクライアントは私のAPIに直接アクセスします。それらのIPは検証できません。彼らは標準のOS（Android/IOS）を実行しています。
- 他のサーバーは関与していません。
- 電話のIMEI（プライベートと見なされます）にアクセスできません。エンドユーザーがわからないため、これも役に立ちません。
- APIにアクセスするさまざまな企業が開発した、このような合法的なモバイルアプリケーションがいくつかあります。
- 現在のセキュリティ（ユーザー名/パスワード）は、悪意のある企業によって簡単にハッキングされる可能性があります。この不正な企業は、合法的なモバイルアプリケーションを分解し、ユーザー名/パスワードを違法なアプリケーションにコピーします。彼らはこのアプリケーションと利益を配布します（APIの使用は、資格情報を盗んだ会社に課金されます）。
これは止められますか？
あなたの質問は「これを止めることはできますか？」ですが、システムに関して重要なことは、実際には変更できない/変更できないと感じています。
私が正しく理解しているなら、あなたは尋ねています（簡略化されています）：
多くのクライアントが同じユーザー名とパスワードを共有しています。誤用をやめることはできますか？
その答えはnoです。問題を無視するか、正しい解決策を実装できるかを判断する必要があります。
本当にこれを適切に実行したい場合は、OAuthなどの実装を検討してください。そうすることで、エンドユーザーに個別の認証トークンを適切に配布し、それらをクライアントにリンクして、請求、アクセスの取り消しなどを行うことができます。
-
あなたがすべき最低限のことは、クライアント（会社）がより良い認証スキームを使用することを選択できるようにすることです。したがって、たとえば、エンドユーザー用に個別のアクセストークンをリクエスト（および取り消し）するためのAPIを作成します。
- A社はサーバーにトークンをリクエストします（これは、「トークンをくれ」とアプリから指示されて開始されます）
- トークンNを返し、接続先の会社を記録します
- A社のアプリがサービスに接続する場合、ユーザー名/パスワードではなくトークンNを送信します
- A社はサービスに「トークンNを取り消す」ことを伝えることができ、そのトークンを使用したそれ以上のリクエストはサービスによって処理されません。ただし、トークンが取り消されても、すべてのクライアントアプリが使用できなくなるわけではありません。
会社がこれを望まない場合でも、ユーザー名/パスワードを使用して接続を継続できますが、結果として生じるすべての使用について完全に責任を負います。
重要なのは、クライアントがサービスを使用する他の方法がない場合は、資格情報の漏えい（モバイルアプリのシナリオでは実行できないこと）に対してクライアントに責任を負わせることができないということです。
だから私はこれが正しいことを願っています。有効なAPIキーを使用してクライアントのIDを確認する安全な方法が必要ですか？ APIキーを安全に保存することは、アプリケーションを開発した会社の責任であり、会社の責任ではないと私は思います。
カジュアルなハッカーからキーを保護するには、キーを暗号化して難読化する必要がありますが、決定的なハッカーを防ぐことができるとは思いません。バイナリをデバッグしにくくするために少しハッカーをかけると、インターネット上でアプリがフロートする可能性を減らすことができます。ただし、これは絶対的なセキュリティではありません。社内でアプリケーションを開発しているのでない限り、このような対策をどのように実施できますか？
ですから、あなたのシナリオへの答えとして、いいえ、ユーザーエクスペリエンスに悪影響を与えずに効果的に停止できるとは思いません。 APIを使用して企業を教育することができます。それらの小さなハンドブックを一緒に投げて、それがtheirを維持する責任their apiキーを安全に保つことであることを明確にしてください。
あなたの側では、いくつかの緩和機能を実装することもできます。例えば：
- 企業が独自のハードリミットを定義できるようにします。会社Aが先月、アプリのダウンロードがN回あったため、APIへのアクセスを1日または1時間あたりXリクエストに制限したいとします。
- 期間ごとの会社ごとの要求の急増を監視します。
- 潜在的な不正行為で発生する可能性のある手順のステップを定義します。
- 再キー、再キー、および再キー。
失敗した場合の目標（最善の結果が得られます）は、損傷を最小限に抑えることです。
幸運を。
クライアントがすべてのユーザーに渡すモバイルアプリにユーザー名/パスワードを埋め込むことについて懐疑的であるのは当然です。正しく特定したように、一部の攻撃者はそのモバイルアプリを分解し、モバイルアプリからユーザー名/パスワードを引き出して、独自のアプリで使用するのは簡単です。残念ながら、それを行うかどうかはクライアントが決定しますが、コストはあなたに課せられます。したがって、これは外部性であり、コストとリスクおよびインセンティブをより適切に調整するためのいくつかの方法が必要になります。その方法について、以下にいくつかの提案があります。
一般的に言えば、これに対する2つのもっともらしい解決策があります。
リスク転送。クライアントごとに、そのクライアントから受け入れるリクエストの数に制限を課します。ユーザー名/パスワードを安全に保つことはクライアントの責任であること、このユーザー名/パスワードを使用して到着するすべてのリクエストは制限に対してカウントされること、およびリクエストが多すぎる場合はアカウントが無効になる可能性があることをクライアントに伝えます。ユーザー名/パスワードをモバイルアプリに埋め込んだ場合、悪意のあるユーザーがユーザー名/パスワードを盗んでそれを使用して多くのリクエストを送信し、アカウントが無効になり、モバイルアプリが機能しなくなるおそれがあることを伝えます。 。リスクを取るかどうかを彼らに決めさせてください。
契約上の要件。ユーザー名/パスワードを他人と共有することは禁止されていることをクライアントに伝え、他人がダウンロードできるアプリにユーザー名/パスワードを埋め込むことは許可されていません。このポリシーの違反を検出した場合は、アカウントが無効になり、サーバーに課されるコストが請求される可能性があることを伝えます。
クライアントがモバイルアプリを作成する場合は、モバイルアプリに独自のユーザー名/パスワードを埋め込むのではなく、そのようなリクエストを独自のサーバーにプロキシする必要があることをクライアントに伝えます。つまり、クライアントはクライアントのユーザー名/パスワードを認識できるサーバーをセットアップする必要がありますが、このユーザー名/パスワードはモバイルアプリに埋め込まないでください。クライアントのモバイルアプリはクライアントのサーバーに対して認証を行い、サーバーにリクエストを送信し、サーバーはリクエストをユーザーに転送し、レスポンスをモバイルアプリに転送する必要があります。サーバーはエンドユーザーを認証する必要があります（たとえば、モバイルアプリの各エンドユーザーに、サーバー上に独自のユーザー名/パスワードでアカウントを作成するように要求します）。彼らのサーバーは、ユーザーごとに帯域幅制限を課し、それらの制限を超えるエンドユーザーのアカウントを無効にする必要があります。
また、クライアントがこれら2つのオプションのいずれかを選択できるようにすることもできます。たとえば、帯域幅が制限されたアカウント（リスク転送あり）、または帯域幅が制限されていないアカウント（他のユーザーがアクセスできるアプリにユーザー名/パスワードを埋め込まないという要件） ）。
これが理にかなっているといいのですが。 3つのパーティーがあるため、これは少し混乱するかもしれません-あなた、あなたのクライアント、そしてあなたのクライアントのエンドユーザー-それぞれが自分の興味と懸念。 3つすべてを適切に区別できれば幸いです。
SSLを使用して送信中のデータを保護することで、中間者攻撃はすでにカバーされています。ソースコードにハードコーディングされたパスワードは、いずれにしても安全な方法ではありません。ユーザーのIPアドレスやIMEIを気にする必要はありません。追跡について話さずに、最初から物事を修正してみましょう。
あなたが言ったように、あなたはRESTを使用しています。あなたを助けるものはほとんどないと思います。
- サーバー側からユーザーを認証します。偽造できないように、厳密なセッション管理を維持してください。これについてはOWASPをチェックしてください。
- APIのファズテストを実行します。 ReSTはいくつかの脆弱性で知られています。インターネット上でそれらを探索し、ReSTの既知のバグのほとんどを知るようにしてください。 APIのこれらの問題にパッチを適用します。
- SSLは、データを途中で保護している点で優れています。
ソースコードについて心配する必要はありません。とにかくそれを引き出すことができますが、それは大丈夫です。主な機能はサーバー上で実行され、クライアントに応答を渡すだけです。サーバー側にすべての良いものを保管してください。
モバイルで直面すると思われる問題の1つは、IPアドレスの検証です。通常、電話会社によって割り当てられたモバイルIPアドレスはネッティングされます。ネット化されたIPは、IP検証メカニズムをサーバーサイドで使用しないようにします。
Android and Iphone'sにソリューションを実装するには、アプローチは次のようにする必要があります。
- SSLモードのクライアントサーバー認証をクライアント証明書の検証にも拡張します。つまり、クライアントとサーバーの両方が証明書を使用して安全なSSLセッションを確立できるようにします。
- PINおよびIMEIとIMSI番号の組み合わせを必要とするような方法で、クライアント証明書（モバイル）を含むPFX/P12を配信します。これにより、攻撃者が拒否することは困難になります同じセッション。
- 同じクライアント証明書を使用して開始された2つ以上の同時セッションを検出するいくつかのAIをサーバーに実装します。これにより、何らかの侵害が発生したことが通知され、サーバーは証明書をすぐにブラックリストに登録するか、失効させてさらに使用できます。
私はモバイル環境について話し合っていたと思います。 IP検証以外に、リスクはPC環境にも存在します。将来的には、PC環境での署名ベースおよびクライアント証明書ベースの実装を採用または移行することもできます。また、クライアントから請求の問題が発生した場合も同様です。
詐欺は危険であり、技術的な実装だけでは対処できませんが、エスカレートされたIP検証とロックダウンを実装した場合は、何も心配する必要はありません。また、クライアント（B2B）に実際の資格情報を提供してはなりません。その理由と方法を説明しましょう。
あなたが何を書いたかについての私の理解から、B2B側（YOURCOMPANY-YOURCLIENT）に関して、基本から平均のセキュリティの概念と実装がすでに適用されています。それは良い。 IP検証、SSL/TLS、ユーザー/パスなど。ここで、モバイルアプリケーションをエンドユーザーに配信するためにクライアントが使用するAPI資格情報に、サードパーティのエンドユーザーが利用する方法に欠陥があることに懸念があります。クライアントのモバイルアプリが何らかの方法で悪用された場合、これらの資格情報。
基本的には、一連のセキュリティ層に要約されます。問題は、あなたの会社がこれらのレイヤーをどのように設計および実装したかです。
JSON/REST APIサーバーには、実際の認証情報が含まれている必要があります。サービスを提供していて、ネットワークプロバイダー/キャリアへの接続が必要な場合は、これらの資格情報もここにあります。私の言っていることが分かるよね。
YOURCLIENTにJSON/REST APIサーバーへの直接アクセスを許可しないでください。代わりに、信頼できる環境のホストとして機能するジャンプホストが必要です。JSON/ RESTアプリケーションが存在するAPIサーバーは、IPアドレスの検証/ロックダウンを使用してこのサーバーでのみ認証する必要があります。 IPまたは公開/秘密キーのペアを使用したサーバー間認証。何を使うかはあなたの裁量です。
このサーバーは、ユーザー名とパスワードのセットを含むWebサービスとしても機能し、それ自体を構成ファイルにマップして、リクエストをJSON/REST APIサーバーに渡します。これで、あなたのクライアントはIP検証/ロックダウンに基づいてこのサーバーにアクセスでき、HTTPSを使用して保護されているはずです。概念は、API SERVERにマップするキー/シークレットを除いて、実際のユーザー/パス資格情報はここには見つからないということです。
- YOURCLIENTは、自分の側からエンドユーザーにセキュリティを実装できます。これは、開発者向けのPKI公開/秘密鍵ペア、または一般ユーザー向けの2FAの形式にすることができます。 YOURCLIENTは、会社ではなく、これらの手順を実装する必要があります。
たとえば、サードパーティの開発者（エンドユーザー）がYOURCLIENTの1人が作成したモバイルアプリケーションの欠陥を悪用し、その資格情報を入手したとします。
- 役に立たない。資格情報を使用するために、IPが検証されます。
- 無効。公開鍵/秘密鍵のペアを介して認証されている必要があることについて。
- 権限昇格手法では、信頼されるために実際のサーバーを悪用する必要があります。
- 実際のサーバーを悪用するには、攻撃者のモチベーションを低下させる巧妙な手法が必要です。
- 動機が終わった成功した攻撃はありません。
難読化は適切であり、攻撃の速度を低下させますが、セキュリティの形式としては最小です。あなたはキーを使用する暗号にもっと頼るべきです。
技術的および運用上のセキュリティの観点から詐欺に対抗するための継続的な取り組みを除けば、絶対的なセキュリティソリューションはありません。