情報の漏えいInformation Disclosure

情報が漏えいすると、攻撃者はシステムに関する重要情報を入手できます。Information disclosure enables an attacker to gain valuable information about a system. そのため、どのような情報を公開しているか、また、その情報が悪意のあるユーザーによって使用される可能性があるかどうかに常に気を配る必要があります。Therefore, always consider what information you are revealing and whether it can be used by a malicious user. 考えられる情報漏えい攻撃とその軽減策を以下に示します。The following lists possible information disclosure attacks and provides mitigations for each.

メッセージ セキュリティと HTTPMessage Security and HTTP

HTTP トランスポート層でメッセージ レベルのセキュリティを使用している場合は、メッセージ レベルのセキュリティで HTTP ヘッダーが保護されないことに注意してください。If you are using message-level security over an HTTP transport layer, be aware that message-level security does not protect HTTP headers. HTTP ヘッダーを保護する唯一の方法は、HTTP ではなく、HTTPS トランスポートを使用することです。The only way to protect HTTP headers is to use HTTPS transport instead of HTTP. HTTPS トランスポートを使用すると、HTTP ヘッダーを含むメッセージ全体が SSL (Secure Sockets Layer) プロトコルを使用して暗号化されます。HTTPS transport causes the entire message, including the HTTP headers, to be encrypted using the Secure Sockets Layer (SSL) protocol.

ポリシー情報Policy Information

ポリシーをセキュリティで保護することが重要です。特に、機密事項が含まれる発行済みトークンの要件や、トークン発行者の情報がポリシーで公開されるフェデレーション シナリオでは重要です。Keeping policy secure is important, especially in federation scenarios where sensitive issued-token requirements or token-issuer information is exposed in policy. このような場合は、フェデレーション サービスのポリシー エンドポイントをセキュリティで保護し、発行済みトークンに含まれるクレームの種類などサービスに関する情報が攻撃者の手に渡らないようにしたり、クライアントが悪意のあるトークン発行者にリダイレクトされたりしないようにすることをお勧めします。In these cases, the recommendation is to secure the federated service's policy endpoint to prevent attackers from obtaining information about the service, such as the type of claims to put in the issued token, or redirecting clients to malicious token issuers. たとえば、攻撃者は、フェデレーション信頼チェーンが man-in-the-middle 攻撃を実行する発行者で終了するように再構成することで、ユーザー名/パスワードのペアを発見することがあります。For example, an attacker could discover user name/password pairs by reconfiguring the federated trust chain to terminate in an issuer that executed a man-in-the-middle attack. また、ポリシーの取得によってバインディングを取得するフェデレーション クライアントの場合は、取得したフェデレーション信頼チェーンに含まれる発行者の信頼性を検証することもお勧めします。It is also recommended that federated clients who obtain their bindings through policy retrieval verify that they trust the issuers in the obtained federated trust chain. フェデレーション シナリオの詳細については、次を参照してください。フェデレーションします。For more information about federation scenarios, see Federation.

メモリ ダンプによるクレーム情報の漏えいMemory Dumps Can Reveal Claim Information

アプリケーションにエラーが発生した場合、ワトソン博士などによって作成されたログ ファイルには、クレーム情報が含まれることがあります。When an application fails, log files, such as those produced by Dr. Watson, can contain the claim information. この情報はサポート チームなどの他のエンティティに対してエクスポートしないでください。プライベートなデータを含むクレーム情報もエクスポートされます。This information should not be exported to other entities, such as support teams; otherwise, the claim information that contains private data is also exported. ログ ファイルを未知のエンティティに送信しないようにすることで、クレーム情報が漏えいするリスクを軽減できます。You can mitigate this by not sending the log files to unknown entities. 詳細については、次を参照してください。 Windows Server 2003します。For more information, see Windows Server 2003.

エンドポイント アドレスEndpoint Addresses

エンドポイント アドレスには、エンドポイントとの通信に必要な情報が含まれます。An endpoint address contains the information needed to communicate with an endpoint. SOAP セキュリティでは、クライアントとサーバーとの間で対称キーをネゴシエートするために交換されるセキュリティ ネゴシエーション メッセージに、完全なアドレスが含まれている必要があります。SOAP security must include the address in full in the security negotiation messages that are exchanged in order to negotiate a symmetric key between a client and a server. セキュリティ ネゴシエーションはブートストラップ プロセスであるため、このプロセスの間、アドレス ヘッダーを暗号化することはできません。Because security negotiation is a bootstrap process, the address headers cannot be encrypted during this process. したがって、アドレスには機密データを含めないようにします。そうしないと、情報漏えい攻撃につながります。Therefore, the address should not contain any confidential data; otherwise, it leads to information disclosure attacks.

暗号化されていない証明書の転送Certificates Transferred Unencrypted

クライアントの認証に X.509 証明書を使用する場合、証明書は SOAP ヘッダー内で暗号化されずに転送されます。When you use an X.509 certificate to authenticate a client, the certificate is transferred in the clear, inside the SOAP header. これは潜在的に個人を特定できる情報 (PII) の漏えいにつながるので注意が必要です。Be aware of this as a potential personally identifiable information (PII) disclosure. トランスポート レベルのセキュリティでメッセージが暗号化される TransportWithMessageCredential モードでは、これは問題とはなりません。This is not an issue for TransportWithMessageCredential mode, where the entire message is encrypted with transport-level security.

サービス参照Service References

サービス参照は、別のサービスへの参照です。A service reference is a reference to another service. たとえば、サービスは、操作の過程でクライアントにサービス参照を渡すことがあります。For example, a service may pass a service reference to a client in the course of an operation. サービス参照を併用しても、 id 検証機能を信頼、アプリケーション データをターゲットに資格情報などの情報を公開する前にターゲット プリンシパルの id を保証する内部コンポーネントです。The service reference is also used with a trust identity verifier, an internal component that ensures the identity of the target principal before disclosing information such as application data or credentials to the target. リモートの信頼できる ID が検証できない、または正しくない場合、送信側は、送信者自身、アプリケーション、またはユーザーが侵害されるおそれのあるデータを開示しないようにする必要があります。If the remote trust identity cannot be verified or is incorrect, the sender should ensure that no data was disclosed that could compromise itself, the application, or the user.

回避策は次のとおりです。Mitigations include the following:

  • サービス参照は信頼できるものと仮定されています。Service references are assumed to be trustworthy. サービス参照インスタンスを転送する場合は、改ざんされていないことを必ず確認するよう注意してください。Take care whenever transferring service reference instances to ensure that they have not been tampered with.

  • 一部のアプリケーションで得られるユーザー エクスペリエンスでは、サービス参照内のデータと、リモート ホストによって信頼性が証明されているデータに基づいて、対話により信頼を確立することができます。Some applications can present a user experience that allows interactive establishment of trust based on data in the service reference and trust data proven by the remote host. WCF では、このような機能は、の機能拡張ポイントが用意されていますが、ユーザーが実装する必要があります。WCF provides extensibility points for such a facility, but the user must implemented them.

NTLMNTLM

Windows ドメイン環境の既定では、Windows 認証は Kerberos プロトコルを使用して、ユーザーの認証と承認を行います。By default, in the Windows domain environment, Windows authentication uses the Kerberos protocol to authenticate and authorize users. 何かの理由で Kerberos プロトコルを使用できない場合は、その代替システムとして NTLM (NT LAN Manager) が使用されます。If the Kerberos protocol cannot be used for some reason, NT LAN Manager (NTLM) is used as a fallback. AllowNtlm プロパティを false に設定することで、この動作を無効にできます。You can disable this behavior by setting the AllowNtlm property to false. NTLM を許可する場合は、次の点に注意してください。Issues to be aware of when allowing NTLM include:

  • NTLM はクライアントのユーザー名を公開します。NTLM exposes the client user name. ユーザー名を非公開にしておく必要がある場合は、バインディングの AllowNTLM プロパティを false に設定します。If the user name needs to be kept confidential, then set the AllowNTLM property on the binding to false.

  • NTLM は、サーバー認証を提供しません。NTLM does not provide server authentication. したがって、認証プロトコルとして NTLM が使用されていると、クライアントは自分が適切なサービスと通信しているかどうかを確認できません。Therefore, the client cannot ensure that it is communicating with the right service when you use NTLM as an authentication protocol.

クライアント資格情報または無効な ID の指定による強制的な NTLM の使用Specifying Client Credentials or Invalid Identity Forces NTLM Usage

クライアントの作成時に、ドメイン名なしでクライアント資格情報を指定するか、無効なサーバー ID を指定すると、Kerberos プロトコルではなく NTLM が使用されます (AllowNtlm プロパティが true に設定されている場合)。When creating a client, specifying client credentials without a domain name, or specifying an invalid server identity, causes NTLM to be used instead of the Kerberos protocol (if the AllowNtlm property is set to true). NTLM ではサーバー認証を行わないため、情報が漏えいするおそれがあります。Because NTLM does not do server authentication, information can potentially be disclosed.

たとえばは、ドメイン名なしの Windows クライアントの資格情報を指定すること Visual c# コードを次に示すようにします。For example, it is possible to specify Windows client credentials without a domain name, as shown in the following Visual C# code.

MyChannelFactory.Credentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password");

このコードではドメイン名が指定されておらず、そのため NTLM が使用されます。The code does not specify a domain name, and therefore NTLM will be used.

ドメインを指定していても、エンドポイント ID 機能を使用して無効なサービス プリンシパル名を指定した場合は、NTLM が使用されます。If the domain is specified, but an invalid service principal name is specified using the endpoint identity feature, then NTLM is used. エンドポイント id を指定する方法の詳細については、次を参照してください。サービス Id と認証します。For more information about how endpoint identity is specified, see Service Identity and Authentication.

関連項目See also