RESTful認証とセッション管理に関するセキュリティの問題
マイクロサービスの認証とセッション管理を実装しようとしています。プロセスをRESTfulに実行するには、サーバー上のクライアントセッションデータの追跡を回避するために、何らかのトークンベースの認証を使用する必要があることを理解しています。情報セキュリティスタックExchangeの この回答 からの次の引用は、実装についての私の理解をうまく要約しています。
トークンベースの認証では、セッションはサーバー側に保持されません（ステートレス）。最初の手順は同じです。資格情報はトークンと交換され、トークンは後続のすべてのリクエストに添付されます（Cookieに保存することもできます）。ただし、メモリ使用量の削減、簡単な拡張性、全体的な柔軟性を目的として、必要なすべての情報を含む文字列が発行され（トークン）、クライアントからサーバーへの各要求の後にチェックされます。
これにより、説明したように、ステートレスセッションメンテナンスがスケーラビリティと柔軟性にどのように有利であるかがわかります。しかし、これにより、アプリケーションがいくつかの深刻な問題にさらされることになります。
- ハッカーがクレデンシャル交換HTTP REST呼び出しを何らかの方法で傍受した場合、サーバーで リプレイ攻撃 を実行して、必要なすべての情報を入手できます。
- 実際、セッショントークンはクライアント側に保存されているため、ハッカーはアプリをデバッグしてLocalStorage/SessionStorageから必要な情報を取得するだけでは不十分でしょうか？または、開発ツールを使用して着信および発信HTTP呼び出しを監視することによって？必要なトークン情報（暗号化されたトークン情報も含む）を取得した場合、別のウィンドウからRESTサーバーへの呼び出しを偽造して、必要なすべてのデータを取得できます。
- 最後に、クライアントにセッショントークンを与えたとしても、サーバーはthatトークンを認証する必要はありませんか？事実上、サーバーはユーザーマッピングへのセッショントークンを維持する必要があります...しかし、それはステートレスRESTベースのアーキテクチャの目的を無効にしませんか？
私の理解にギャップがあるので、多分私はこれらの問題を見ています。その場合は、基本的な概念をいくらか明確にしてください。そうでない場合は、これらの特定の問題に対処するためのテクニックがあるかどうかを知りたいです。
この回答 は、ネットワークレベルでのリプレイ攻撃に関して役立つ場合があります。 「nonce」を使用すると、同じクライアントによって同じセマンティック要求が複数回行われるのを防ぐこともできます。
Man In The Middle（MITM）がハッシュをインターセプトし、パスワードの代わりにそれを再生することに関しては、これが可能であることは事実ですが、状態がサーバーに保存されており、プレーンセッショントークンCookieが交換されますが、強力な構成（強力な暗号、EDHC、最新のプロトコル、プリロード付きのHSTS、場合によってはHPKP）を使用してHTTPSを使用することで、どちらの場合もさらに困難にする必要があります。 https://www.ssllabs.com/ssltest / 構成をテストします。
securehttp only cookies を使用すると、 [〜＃〜] csp [〜＃〜] のように、偶発的な状態の開示から保護することもできます不正なスクリプトが抽出を実行しようとしています。
[〜＃〜] jwt [〜＃〜] で使用されているようなプロセスは、悪意のあるクライアントがローカルストレージまたはCookieを開いて変更する心配からあなたを保護するのに役立つ可能性があります（たとえば、誰かが試みているサーバーに送信されるローカル状態を変更するため）。公開鍵インフラストラクチャ（PKI）を利用して、秘密鍵を安全に保つことで、この手法はデジタル署名の検証に効果的です（サーバーで読み取るときにクライアントの状態が変更されていないことを確認します）。これは、質問パート3で指摘したように、サーバーはクライアントトークンを検証するために必ずしもマップする必要はなく、データを信頼する前にメッセージの整合性を確保するためにHMACを検証する必要があります。
より広いレベルでは、スケーラビリティの面で多くの利点をもたらす一方で、クライアントでクライアントの状態を維持することに厳格に落ち着いていると、ここで述べたようないくつかの課題が生じ、多くの場合、サーバー側の管理状態で許容可能なスケーラビリティを実現できます。レプリケーションとパーティショニングにより、障害をユーザーのより小さなサブセクションに分離します。例えば。 RedisとAWS Elasticacheのような管理されたホスティングについて考えてください。状態がクライアントで排他的に管理されている場合、失効や早期期限切れなどを行うのが難しくなる可能性があります。
これが何らかの形で役立つことを願っています、
Q：1-2はい、発生する可能性があります。他のユーザーが認証トークンを盗んだ場合、ハッカーは他のユーザーになりすますことができます。ただし、ユーザーのクライアントにアクセスするためには、（通常は）が必要です。
プロセス間通信に関しては、サーバーとクライアントの通信が安全である場合（暗号化）、中間者が攻撃者に適切なデータを提供することはありません。そのため、分散システムではTLSが非常に重要です。1
盗まれたトークンに戻り、この脆弱性を軽減するために、トークンを短命にすることがよくあります。トークンは最終的に期限切れになり、クライアントは認証トークンを再度要求する必要があります。一部のセキュリティ実装は更新トークンを使用し、その他の実装はクライアントに再度ログインを強制します。
サーバー側では、たとえば、トークンを早期に期限切れにしたり、ブラックリストやホワイトリストを実装したりできるなど、いくつかの対策も実装できます。
Q：3サーバーは、すべてのリクエストでトークンを検証します。 DBでそれを探し、そのコンテンツをデコードし、トークンをある種の認証サービスに送信するなど。他の資格情報の場合と同じように。もちろん、トークンをどこかに保存する必要がありますが、トークンはセッションではありません。彼らはクライアントの状態を保持せず、ユーザーと許可を識別し、時にはトークンの発行者も識別します。
セッショントークンに関しては、サーバー側が純粋にステートレスである場合、クライアント側の状態に関して保持するものがない場合、識別するセッションはまったくありません。同じ認証トークンがセッショントークンとして機能します。トークンの有効期限が切れるとすぐに、クライアント側のセッションでも有効期限が切れる可能性があります。
1： クロスサイトスクリプティング攻撃 のような他の攻撃ベクトルがあります。潜在的に有害ですが、「比較的」簡単に防ぐことができます。