9

SAML フェデレーション ソフトウェアは、許可された SAML トークンの有効期間内である限り、同じ SAML 応答を受け入れる必要がありますか?

簡単に言えば、 IDP (識別プロバイダー) が SAML 応答を発行し、SP (サービス プロバイダー) がそれを受け入れて処理します。同じ未変更の SAML 応答を最初に使用した直後に再使用できますか? SAML 発行のタイムスタンプが許容範囲内であることを前提としています。

セキュリティ上、SAML トークン (応答) の使用を 1 回だけに制限することは理にかなっています。これにより、たとえ「中間者」によって盗まれたとしても、再利用できなくなります。しかし、それを実装するために、ソフトウェアは SAML 応答に関する情報をどこかに保存する必要があります: シリアル番号、全体のハッシュ?

可能性に関する説明や実装例へのリンクをいくつか提供してください。

ありがとうございました！アレックス。

4

2 に答える 2

10

SAML 2.0 標準は、アサーションの ID をデータベースに格納することを意味しないリプレイ攻撃を防ぐ別の方法を提供します。

  • SP は ID="X" を含むリクエストを送信し、この ID をセッションに保存します。
  • IDP はユーザーを認証し、ID="Y" と InResponseTo="X" (通常、SubjectConfirmationData のアサーションにも存在します) を含む応答を返します。
  • SP は応答を取得し、すべての InResponseTo 値がセッション内の値と一致することを確認します。そうでない場合、SP は応答を拒否します。
  • SP はセッション中に ID をクリアするため、レスポンスの再生が不可能になります。理想的なケースでは、SP は応答を受信するとすぐにセッションの ID をクリアする必要があります。

攻撃者は SP のセッション Cookie も必要とするため、このチェックはリプレイ攻撃を非常に複雑にします (この場合でも、いずれにせよ、すでにゲーム オーバーになっています...)。応答全体に署名することもお勧めします。

明らかに、この方法は SP によって開始されたシナリオでのみ有効です。

于 2014-03-26T20:06:35.283 に答える
6

セキュリティ的に意味がありますか？もちろん。実際、アサーションの「xs:ID」部分を使用して支援することができます (私の会社のソフトウェアはそうしています)。

COREの9ページから：

xs:ID 単純型は、アサーション、リクエスト、およびレスポンスの SAML 識別子を宣言するために使用されます。この仕様でタイプ xs:ID であると宣言された値は、xs:ID タイプ自体の定義によって課されるものに加えて、次のプロパティを満たさなければなりません。

• 識別子を割り当てる当事者は、その当事者または他の当事者が誤って同じ識別子を別のデータ オブジェクトに割り当てる可能性がごくわずかであることを確認する必要があります。

• データ オブジェクトが特定の識別子を持つことを宣言する場合、そのような宣言が 1 つだけ存在する必要があります。

その ID をアサーションから取得し、それを not-after 時間とともに配列にドロップし、その時間が経過したらそれを破棄します。このようにして、同じアサーションを再生することはできません。

他のソフトウェア (特に自家製のもの) では、これは対象者制限の Not-Before および Not-On-Or-After 部分で完全に管理されます。一部のソフトウェアはこれらの値のみを考慮に入れるため、この期間をできるだけ短く設定することをお勧めします。完璧な世界では、誰もがタイム サーバーを使用しており、そのクロック スキューは数秒以内です。1 分前、1 分後の発行時間で十分すぎるはずです。ここには「セキュリティ」はあまりありませんが、「管理」できます。

于 2014-03-15T12:47:36.693 に答える