0

SSO を実装するために次のスキームを使用します -

初期ログイン -

  1. ユーザーがクライアント アプリをロードするたびに、SSO ログイン ページにリダイレクトされます。
  2. ユーザーがログインすると、暗号化された Cookie トークンがクライアントに設定され、その値もセッションに保存されます。

別のアプリへのアクセス -

  1. ユーザーが別のクライアント アプリをロードすると、SSO ログイン ページに再度リダイレクトされます。
  2. SSO モジュールは、最初に暗号化された Cookie が存在するかどうかを確認し、次にその値をセッション内の値と比較します。
  3. これらの両方が一致する場合、ユーザーは認証済みとしてリダイレクトされます。
  4. または、ユーザーにユーザー名/パスワードの入力を求めます。

このスキームにセキュリティ上の脆弱性はありますか?

ありがとう、ムルタザ

4

1 に答える 1

1

設計は、SSO スキームとしてはかなり標準的なようです。もちろん、概念が安全であっても、スキームの実装に脆弱性が生じる可能性があります。たとえば、安全な実装では、SSO 認証 Cookie の侵害や、依存システムへの ID アサーションの脆弱性を防ぐ必要があります。さらに、単一の資格情報を使用して複数のアプリケーションを認証できる SSO 環境では、認証メカニズム自体の脆弱性 (脆弱なパスワードなど) が増幅される可能性があります。

暗号化された Cookie とセッションの両方を使用して依存アプリケーションに対してエンド ユーザーを識別することは冗長である可能性があり、動機がセッション ハイジャック攻撃から防御することである場合は効果的でない可能性があります。これらの Cookie を含む HTTP リクエストが平文で送信されると、セッション ID と暗号化された Cookie 暗号文の両方が平文で送信され、なりすましの脆弱性が生じる可能性があります。(もちろん、Cookie のクリアテキストは送信されませんが、攻撃者は Cookie の暗号文コンテンツのみを必要とします。) この脅威を軽減するには、セッション Cookie を安全なものとして設定し、SSO ログイン ページに SSL 経由でのみアクセスできるようにする必要があります。

暗号化された Cookie の動機が、セッションの存続期間を過ぎても資格情報を保存できるようにすることである場合は、適切な暗号化手法を使用するように注意する必要があります (たとえば、キー管理と標準暗号化アルゴリズムの使用)。もちろん、Cookie は (実用的な目的で) クリアテキストで送信されないようにするために、安全であるとマークする必要があります。重複を防ぐために各アサーションの後に Cookie を更新する、有効期間を制限する (たとえば、x日ごとに再認証を要求する) などの他の対策が必要になる場合があります。

このスキームでは、検証者がエンド ユーザーの認証に成功した後、RP に対して ID アサーションを行うことも必要です。これには、 OAuthやOpenIDなど、いくつかの標準プロトコルがあります。

最後に、ユーザーは SSO セッションを終了して、ユーザーがセッションを離れたときに無許可のアクセスを防止する必要があります。

もちろん、信頼するシステムの保証要件を考慮する必要があります。SSO システムが侵害された場合のリスク (可能性と影響の観点から) はどのようなものでしょうか? リスクが増大するにつれて、侵害から防御するための戦略的および運用上の対策 (リスクおよび脆弱性の評価など) の費用対効果も増大します。

于 2012-07-18T10:56:14.847 に答える