権限の昇格Elevation of Privilege

特権の昇格によって、最初に許可された権限以外に攻撃者の承認アクセス許可が付与されます。Elevation of privilege results from giving an attacker authorization permissions beyond those initially granted. たとえば、"読み取り専用" アクセス許可の権限セットを持つ攻撃者が、何らかの方法で権限セットを "読み取り/書き込み" アクセス許可を含むものに昇格させます。For example, an attacker with a privilege set of "read only" permissions somehow elevates the set to include "read and write."

SAML トークンのクレームには信頼された STS による署名が必要Trusted STS Should Sign SAML Token Claims

SAML (Security Assertions Markup Language) トークンは、発行済みトークンの既定の型である汎用 XML トークンです。A Security Assertions Markup Language (SAML) token is a generic XML token that is the default type for issued tokens. SAML トークンは、通常の交換においてエンド Web サービスから信頼されたセキュリティ トークン サービス (STS) によって作成できます。A SAML token can be constructed by a Security Token Service (STS) that the end Web service trusts in a typical exchange. SAML トークンには、ステートメント内にクレームが格納されます。SAML tokens contain claims in statements. 攻撃者は、有効なトークンからクレームをコピーして新しい SAML トークンを作成し、別の発行者による署名を行うことがあります。An attacker may copy the claims from a valid token, create a new SAML token, and sign it with a different issuer. この目的は、サーバーが発行者を検証するかどうかを確認し、検証しない場合に、この脆弱性を利用して信頼された STS が意図したものよりも高い権限を与える SAML トークンを作成することです。The intent is to determine whether the server is validating issuers and, if not, utilize the weakness to construct SAML tokens that allow privileges beyond those intended by a trusted STS.

SamlAssertion クラスは、SAML トークンに含まれるデジタル署名を検証します。SamlSecurityTokenAuthenticator クラスの CertificateValidationModeIssuedTokenServiceCredential に設定されている場合、既定の ChainTrust は、SAML トークンが有効な X.509 証明書によって署名されていることを要求します。The SamlAssertion class verifies the digital signature contained within a SAML token, and the default SamlSecurityTokenAuthenticator requires that SAML tokens be signed by an X.509 certificate that is valid when the CertificateValidationMode of the IssuedTokenServiceCredential class is set to ChainTrust. SAML トークンの発行者を信頼できるかどうか判断するには、ChainTrust モードだけでは不十分です。ChainTrust mode alone is insufficient to determine whether the issuer of the SAML token is trusted. より詳細な信頼モデルを必要とするサービスは、承認ポリシーと強制ポリシーを使用して、発行済みトークン認証によって生成されたクレーム セットの発行者をチェックするか、IssuedTokenServiceCredential の X.509 検証設定を使用して、許可する署名証明書のセットを制限できます。Services that require a more granular trust model can either use authorization and enforcement policies to check the issuer of the claim sets produced by issued token authentication or use the X.509 validation settings on IssuedTokenServiceCredential to restrict the set of allowed signing certificates. 詳細については、「Id モデルとフェデレーションおよび発行済みトークンを使用したクレームと承認の管理」を参照してください。For more information, see Managing Claims and Authorization with the Identity Model and Federation and Issued Tokens.

セキュリティ コンテキストを使用しない ID の切り替えSwitching Identity Without a Security Context

次の例は、WinFX にのみ適用されます。The following applies only to WinFX.

クライアントとサーバーの間に接続が確立されている場合、クライアントの id は変更されません。ただし、次の条件がすべて当てはまる場合は、WCF クライアントが開かれた後であることが条件となります。When a connection is established between a client and server, the identity of the client does not change, except in one situation: after the WCF client is opened, if all of the following conditions are true:

  • (トランスポートセキュリティセッションまたはメッセージセキュリティセッションを使用して) セキュリティコンテキストを確立する手順はオフEstablishSecurityContextになっていfalseます (メッセージセキュリティまたはトランスポートがセキュリティを確立できない場合は、プロパティがに設定されます)。セッションは、トランスポートセキュリティのケースで使用されます。The procedures to establish a security context (using a transport security session or message security session) is switched off (EstablishSecurityContext property is set to false in case of message security or transport not capable of establishing security sessions is used in transport security case. トランスポート セキュリティの場合は、セキュリティ セッションを確立できないトランスポート (HTTPS など) が使用されている)。HTTPS is one example of such transport).

  • Windows 認証を使用している。You are using Windows authentication.

  • 資格情報を明示的に設定していない。You do not explicitly set the credential.

  • 偽装されたセキュリティ コンテキストでサービスを呼び出している。You are calling the service under the impersonated security context.

これらの条件に該当する場合は、サービスに対するクライアントの認証に使用される id が変更される可能性があります (偽装された id ではなく、プロセス id ではなく、WCF クライアントが開かれた後)。If these conditions are true, the identity used to authenticate the client to the service might change (it might not be the impersonated identity but the process identity instead) after the WCF client is opened. この状況が発生するのは、サービスに対するクライアントの認証に使用する Windows 資格情報がすべてのメッセージと共に送信され、認証に使用する資格情報が現在のスレッドの Windows ID から取得されるためです。This occurs because the Windows credential used to authenticate the client to the service is transmitted with every message, and the credential used for authentication is obtained from the current thread's Windows identity. (たとえば、別の呼び出し元を偽装することによって) 現在のスレッドの Windows ID が変更された場合、メッセージに添付され、サービスに対するクライアントの認証に使用する資格情報も変更される可能性があります。If the Windows identity of the current thread changes (for example, by impersonating a different caller), the credential that is attached to the message and used to authenticate the client to the service might also change.

偽装と共に Windows 認証を使用する場合に動作を確定する必要があるときは、Windows 資格情報を明示的に設定するか、サービスでセキュリティ コンテキストを確立する必要があります。If you want to have deterministic behavior when using Windows authentication together with impersonation you need to explicitly set the Windows credential or you need to establish a security context with the service. これを行うには、メッセージ セキュリティ セッションまたはトランスポート セキュリティ セッションを使用します。To do this, use a message security session or a transport security session. たとえば、net.tcp トランスポートは、トランスポート セキュリティ セッションを提供します。For example, the net.tcp transport can provide a transport security session. また、サービスの呼び出し時に、クライアント操作の同期バージョンだけを使用する必要があります。Additionally, you must use only a synchronous version of client operations when calling the service. メッセージ セキュリティ コンテキストを確立する場合は、構成済みセッションの更新時間よりも長い時間、サービスへの接続を開いたままにしないようにしてください。セッション更新プロセスの間にも ID が変更される可能性があるためです。If you establish a message security context, you should not keep the connection to the service open longer than the configured session renewal period, because the identity can also change during the session renewal process.

資格情報のキャプチャCredentials Capture

次の内容は、.NET Framework version 3.5.NET Framework version 3.5 以降のバージョンに適用されます。The following applies to .NET Framework version 3.5.NET Framework version 3.5, and subsequent versions.

クライアントまたはサービスが使用する資格情報は、現在のコンテキストのスレッドに基づきます。Credentials used by the client or the service are based on the current context thread. 資格情報は、クライアントまたはサービスの Open メソッド (または、非同期呼び出しの場合は BeginOpen) が呼び出された場合に取得されます。The credentials are obtained when the Open method (or BeginOpen, for asynchronous calls) of the client or service is called. ServiceHost クラスおよび ClientBase<TChannel> クラスのいずれの場合も、Open メソッドおよび BeginOpen メソッドは、Open クラスの BeginOpen メソッドおよび CommunicationObject メソッドから継承されます。For both the ServiceHost and ClientBase<TChannel> classes, the Open and BeginOpen methods inherit from the Open and BeginOpen methods of the CommunicationObject class.

注意

BeginOpen メソッドを使用する場合、キャプチャされた資格情報は、このメソッドを呼び出したプロセスの資格情報であることが保証されません。When using the BeginOpen method, the credentials captured cannot be guaranteed to be the credentials of the process that calls the method.

トークン キャッシュによる以前のデータを使用した再生の許可Token Caches Allow Replay Using Obsolete Data

WCF では、ユーザー名とパスワードにLogonUserよってユーザーを認証するために、ローカルセキュリティ機関 (LSA) の機能が使用されます。WCF uses the local security authority (LSA) LogonUser function to authenticate users by user name and password. Logon 関数はコストのかかる操作なので、WCF では、認証されたユーザーを表すトークンをキャッシュしてパフォーマンスを向上させることができます。Because the logon function is a costly operation, WCF allows you to cache tokens that represent authenticated users to increase performance. キャッシュ機構は、それ以降に使用できるように LogonUser の結果を保存します。The caching mechanism saves the results from LogonUser for subsequent uses. このメカニズムは、既定では無効になっています。有効にするには、 CacheLogonTokensプロパティをtrueに設定するかcacheLogonTokens <userNameAuthentication >の属性を使用します。This mechanism is disabled by default; to enable it, set the CacheLogonTokens property to true, or use the cacheLogonTokens attribute of the <userNameAuthentication>.

CachedLogonTokenLifetime プロパティを TimeSpan に設定するか、cachedLogonTokenLifetime 要素の userNameAuthentication 属性を使用することで、キャッシュされたトークンの有効期間 (TTL) を設定できます。既定値は 15 分です。You can set a Time to Live (TTL) for the cached tokens by setting the CachedLogonTokenLifetime property to a TimeSpan, or use the cachedLogonTokenLifetime attribute of the userNameAuthentication element; the default is 15 minutes. Windows からユーザー アカウントが削除された場合や、パスワードが変更されている場合でも、トークンがキャッシュされている間は、同じユーザー名とパスワードを指定すると、どのクライアントもこのトークンを使用できます。Note that while a token is cached, any client that presents the same user name and password can use the token, even if the user account is deleted from Windows or if its password has been changed. TTL が期限切れになり、トークンがキャッシュから削除されるまで、WCF では (悪意のある可能性がある) ユーザーの認証を許可します。Until the TTL expires and the token is removed from the cache, WCF allows the (possibly malicious) user to authenticate.

これを軽減するには:ユーザーが必要とする最短のcachedLogonTokenLifetime期間に値を設定して、攻撃ウィンドウを減らします。To mitigate this: Decrease the attack window by setting the cachedLogonTokenLifetime value to the shortest time span your users need.

発行されたトークン承認:大きな値にリセットする有効期限Issued Token Authorization: Expiration Reset to Large Value

一定の条件下で、ExpirationTimeAuthorizationContext プロパティが予期しない大きな値 (MaxValue フィールド値から 1 日引いた値 (December 20, 9999)) に設定される場合があります。Under certain conditions, the ExpirationTime property of the AuthorizationContext may be set to an unexpectedly larger value (the MaxValue field value minus one day, or December 20, 9999).

これは、WSFederationHttpBinding、およびクライアント資格情報の種類が発行済みトークンであるシステム提供のバインディングを使用している場合に発生します。This occurs when using the WSFederationHttpBinding and any of the system-provided bindings that have an issued token as the client credential type.

また、以下のメソッドのいずれかを使用して、カスタム バインドを作成した場合にも発生します。This also occurs when you create custom bindings by using one of the following methods:

これをできるだけ防ぐには、承認ポリシーによって各承認ポリシーのアクションと有効期限をチェックする必要があります。To mitigate this, the authorization policy must check the action and the expiration time of each authorization policy.

クライアントで予定していたものと異なる証明書をサービスで使用する場合The Service Uses a Different Certificate Than the Client Intended

一定の条件下で、クライアントが X.509 証明書を使用してメッセージにデジタル署名したときに、予定していたものと異なる証明書をサービスが取得する場合があります。Under certain conditions, a client can digitally sign a message with an X.509 certificate and have the service retrieve a different certificate than the intended one.

これは、次のような状況で発生する可能性があります。This can occur under the following circumstances:

  • クライアントが X.509 証明書を使用してメッセージにデジタル署名したときに、その X.509 証明書をメッセージに添付するのではなく、サブジェクト キー識別子を使用して証明書を参照しているだけの場合。The client digitally signs a message using an X.509 certificate and does not attach the X.509 certificate to the message, but rather just references the certificate using its subject key identifier.

  • サービスのコンピューターに同じ公開キーを持つ複数の証明書が格納されており、それらの証明書に含まれる情報が異なる場合。The service's computer contains two or more certificates with the same public key, but they contain different information.

  • サービスがサブジェクト キー識別子と一致する証明書を取得したが、クライアントが使用する予定だったものではない場合。The service retrieves a certificate that matches the subject key identifier, but it is not the one the client intended to use. WCF は、メッセージを受信して署名を検証するときに、意図しない x.509 証明書の情報を、クライアントが期待するものとは異なる、または昇格された可能性のある一連のクレームにマップします。When WCF receives the message and verifies the signature, WCF maps the information in the unintended X.509 certificate to a set of claims that are different and potentially elevated from what the client expected.

これをできるだけ防ぐには、X.509 証明書を別の方法 (IssuerSerial の使用など) で参照します。To mitigate this, reference the X.509 certificate another way, such as using IssuerSerial.

関連項目See also