特権の昇格は 、最初に付与された権限を超える権限を攻撃者に付与した結果です。 たとえば、"読み取り専用" アクセス許可の特権セットを持つ攻撃者は、そのセットを "読み取りと書き込み" を含むように昇格させます。
信頼された STS が SAML トークン要求に署名する必要がある
Security Assertions Markup Language (SAML) トークンは、発行されたトークンの既定の型である汎用 XML トークンです。 SAML トークンは、エンド Web サービスが一般的な交換で信頼するセキュリティ トークン サービス (STS) によって構築できます。 SAML トークンには、ステートメント内の要求が含まれています。 攻撃者は、有効なトークンから要求をコピーし、新しい SAML トークンを作成し、別の発行者で署名する可能性があります。 この目的は、サーバーが発行者を検証しているかどうかを判断することです。検証されていない場合は、弱点を利用して、信頼された STS が意図した特権を超える特権を許可する SAML トークンを構築します。
SamlAssertion クラスは SAML トークンに含まれるデジタル署名を検証します。既定のSamlSecurityTokenAuthenticatorでは、CertificateValidationMode クラスのIssuedTokenServiceCredentialがChainTrustに設定されている場合に有効な X.509 証明書によって SAML トークンが署名されている必要があります。
ChainTrust
モードだけでは、SAML トークンの発行者が信頼されているかどうかを判断するには不十分です。 より詳細な信頼モデルを必要とするサービスでは、承認ポリシーと適用ポリシーを使用して、発行されたトークン認証によって生成された要求セットの発行者を確認するか、 IssuedTokenServiceCredential の X.509 検証設定を使用して許可される署名証明書のセットを制限できます。 詳細については、「ID モデルとフェデレーションおよび発行済みトークンを使用した要求と承認の管理」を参照してください。
セキュリティ コンテキストのない ID の切り替え
以下は WinFX にのみ適用されます。
クライアントとサーバーの間に接続が確立されている場合、次の条件がすべて満たされている場合、WCF クライアントを開いた後の 1 つの状況を除き、クライアントの ID は変更されません。
セキュリティ コンテキストを確立する手順 (トランスポート セキュリティ セッションまたはメッセージ セキュリティ セッションを使用) がオフになっている (EstablishSecurityContext プロパティは、メッセージ セキュリティの場合、またはトランスポート セキュリティ ケースでセキュリティ セッションを確立できないトランスポートが使用される場合に
false
に設定されます)。HTTPS は、このようなトランスポートの 1 つの例です)。Windows 認証を使用している。
あなたは資格情報を明示的に設定しません。
偽装されたセキュリティ コンテキストでサービスを呼び出しています。
これらの条件が満たされている場合、WCF クライアントを開いた後に、サービスに対するクライアントの認証に使用される ID が変更される可能性があります (偽装された ID ではなく、プロセス ID である可能性があります)。 これは、サービスに対するクライアントの認証に使用される Windows 資格情報がすべてのメッセージで送信され、認証に使用される資格情報が現在のスレッドの Windows ID から取得されるために発生します。 現在のスレッドの Windows ID が変更された場合 (たとえば、別の呼び出し元を偽装するなど)、メッセージにアタッチされ、サービスに対するクライアントの認証に使用される資格情報も変更される可能性があります。
Windows 認証を偽装と一緒に使用する際に、決定論的な動作を得たい場合は、Windows 資格情報を明示的に設定するか、サービスとセキュリティコンテキストを確立する必要があります。 これを行うには、メッセージ セキュリティ セッションまたはトランスポート セキュリティ セッションを使用します。 たとえば、net.tcp トランスポートはトランスポート セキュリティ セッションを提供できます。 さらに、サービスを呼び出すときは、クライアント操作の同期バージョンのみを使用する必要があります。 メッセージ セキュリティ コンテキストを確立する場合は、構成されたセッション更新期間よりも長くサービスへの接続を開いたままにしないでください。これは、ID がセッション更新プロセス中にも変更される可能性があるためです。
資格情報のキャプチャ
以下は、.NET Framework 3.5 以降のバージョンに適用されます。
クライアントまたはサービスによって使用される資格情報は、現在のコンテキスト スレッドに基づいています。 資格情報は、クライアントまたはサービスの Open
メソッド (非同期呼び出しの場合は BeginOpen
) が呼び出されたときに取得されます。
ServiceHostクラスとClientBase<TChannel> クラスの両方で、Open
メソッドとBeginOpen
メソッドは、Open クラスのBeginOpenメソッドとCommunicationObject メソッドを継承します。
注
BeginOpen
メソッドを使用する場合、キャプチャされた資格情報が、メソッドを呼び出すプロセスの資格情報であるとは限りません。
トークン キャッシュでは、古いデータを使用した再生が許可されます
WCF では、ローカル セキュリティ機関 (LSA) LogonUser
関数を使用して、ユーザー名とパスワードでユーザーを認証します。 ログオン関数はコストの高い操作であるため、WCF では、認証されたユーザーを表すトークンをキャッシュしてパフォーマンスを向上させることができます。 キャッシュ メカニズムは、後続の使用のために LogonUser
からの結果を保存します。 このメカニズムは既定で無効になっています。これを有効にするには、CacheLogonTokens プロパティをtrue
に設定するか、cacheLogonTokens
userNameAuthentication<の>属性を使用します。
キャッシュされたトークンの Time to Live (TTL) を設定するには、CachedLogonTokenLifetime プロパティをTimeSpanに設定するか、cachedLogonTokenLifetime
要素のuserNameAuthentication
属性を使用します。既定値は 15 分です。 トークンがキャッシュされている間、ユーザー アカウントが Windows から削除された場合やパスワードが変更された場合でも、同じユーザー名とパスワードを提示するすべてのクライアントでトークンを使用できることに注意してください。 TTL が期限切れになり、トークンがキャッシュから削除されるまで、WCF は (悪意のある可能性がある) ユーザーの認証を許可します。
これを軽減するには: cachedLogonTokenLifetime
値をユーザーが必要とする最短の期間に設定して、攻撃期間を減らします。
発行済みトークンの承認 : 大きな値にリセットされた有効期限
特定の条件下では、ExpirationTimeのAuthorizationContextプロパティが予期せず大きい値 (MaxValue フィールド値から 1 日を引いた値、または 9999 年 12 月 20 日) に設定される場合があります。
これは、 WSFederationHttpBinding と、クライアント資格情報の種類として発行されたトークンを持つシステムによって提供されるバインディングのいずれかを使用する場合に発生します。
これは、次のいずれかの方法を使用してカスタム バインドを作成する場合にも発生します。
これを軽減するには、承認ポリシーで各承認ポリシーのアクションと有効期限を確認する必要があります。
サービスは、クライアントが意図した証明書とは異なる証明書を使用します
特定の条件下では、クライアントは X.509 証明書を使用してメッセージにデジタル署名し、サービスが意図した証明書とは異なる証明書を取得できます。
これは、次の状況で発生する可能性があります。
クライアントは、X.509 証明書を使用してメッセージにデジタル署名し、X.509 証明書をメッセージに添付するのではなく、サブジェクト キー識別子を使用して証明書を参照します。
サービスのコンピューターには、同じ公開キーを持つ 2 つ以上の証明書が含まれていますが、異なる情報が含まれています。
サービスは、サブジェクト キー識別子と一致する証明書を取得しますが、クライアントが使用することを意図した証明書ではありません。 WCF がメッセージを受信して署名を検証すると、WCF は意図しない X.509 証明書の情報を、クライアントが期待していたものとは異なり、昇格される可能性のある一連の要求にマップします。
これを軽減するには、 IssuerSerialの使用など、別の方法で X.509 証明書を参照します。