情報漏えいにより、攻撃者はシステムに関する貴重な情報を取得できます。 したがって、表示している情報と、悪意のあるユーザーが使用できるかどうかを常に検討してください。 次に、考えられる情報漏えい攻撃の一覧を示し、それぞれの軽減策を示します。
メッセージ セキュリティと HTTP
HTTP トランスポート層でメッセージ レベルのセキュリティを使用している場合は、メッセージ レベルのセキュリティでは HTTP ヘッダーが保護されないことに注意してください。 HTTP ヘッダーを保護する唯一の方法は、HTTP ではなく HTTPS トランスポートを使用することです。 HTTPS トランスポートにより、HTTP ヘッダーを含むメッセージ全体が、Secure Sockets Layer (SSL) プロトコルを使用して暗号化されます。
ポリシー情報
特に、発行されたトークンの機密性の高い要件やトークン発行者の情報がポリシーで公開されるフェデレーション シナリオでは、ポリシーのセキュリティを維持することが重要です。 このような場合は、フェデレーション サービスのポリシー エンドポイントをセキュリティで保護して、攻撃者がサービスに関する情報 (発行されたトークンに入れるクレームの種類など) を取得したり、クライアントを悪意のあるトークン発行者にリダイレクトしたりできないようにすることをお勧めします。 たとえば、攻撃者は、中間者攻撃を実行した発行者で終了するようにフェデレーション信頼チェーンを再構成することで、ユーザー名とパスワードのペアを検出できます。 また、ポリシー取得を通じてバインディングを取得するフェデレーション クライアントは、取得したフェデレーション信頼チェーンの発行者を信頼していることを確認することもお勧めします。 フェデレーション シナリオの詳細については、「 フェデレーション」を参照してください。
メモリ ダンプで要求情報を表示できる
アプリケーションが失敗した場合、ワトソン博士によって生成されたログ ファイルなどのログ ファイルに要求情報を含めることができます。 この情報は、サポート チームなどの他のエンティティにエクスポートしないでください。それ以外の場合は、プライベート データを含む要求情報もエクスポートされます。 これは、不明なエンティティにログ ファイルを送信しないことで軽減できます。
エンドポイント アドレス
エンドポイント アドレスには、エンドポイントと通信するために必要な情報が含まれています。 SOAP セキュリティは、クライアントとサーバーの間で対称キーをネゴシエートするために交換されるセキュリティ ネゴシエーション メッセージにアドレスを完全に含める必要があります。 セキュリティ ネゴシエーションはブートストラップ プロセスであるため、このプロセス中にアドレス ヘッダーを暗号化することはできません。 したがって、アドレスには機密データを含めてはなりません。そうしないと、情報漏えい攻撃につながります。
暗号化されずに転送された証明書
X.509 証明書を使用してクライアントを認証すると、証明書は SOAP ヘッダー内のクリアで転送されます。 これは、個人を特定できる可能性のある情報 (PII) の開示として認識してください。 これは、メッセージ全体がトランスポート レベルのセキュリティで暗号化される TransportWithMessageCredential モードの問題ではありません。
サービス参照
サービス参照は、別のサービスへの参照です。 たとえば、サービスは、操作の過程でクライアントにサービス参照を渡すことができます。 サービス参照は、アプリケーション データや資格情報などの情報をターゲットに公開する前に、ターゲット プリンシパルの ID を確保する内部コンポーネントである 信頼 ID 検証ツールでも使用されます。 リモート信頼 ID を検証できない場合、または正しくない場合、送信者は、それ自体、アプリケーション、またはユーザーを侵害する可能性のあるデータが開示されていないことを確認する必要があります。
軽減策には、次のようなものがあります。
サービス参照は信頼できるものと見なされます。 サービス参照インスタンスを転送するときは常に注意して、改ざんされていないことを確認してください。
一部のアプリケーションでは、サービス参照内のデータとリモート ホストによって証明された信頼データに基づいて、対話形式で信頼を確立できるユーザー エクスペリエンスを提供できます。 WCF はこのような機能の拡張ポイントを提供しますが、ユーザーはそれらを実装する必要があります。
NTLM
既定では、Windows ドメイン環境では、Windows 認証は Kerberos プロトコルを使用してユーザーの認証と承認を行います。 何らかの理由で Kerberos プロトコルを使用できない場合は、NT LAN Manager (NTLM) がフォールバックとして使用されます。 この動作を無効にするには、 AllowNtlm プロパティを false に設定します。 NTLM を許可する際に注意する必要がある問題は次のとおりです。
NTLM は、クライアント ユーザー名を公開します。 ユーザー名を秘密にしておく必要がある場合は、バインディングの
AllowNTLMプロパティをfalseに設定します。NTLM では、サーバー認証は提供されません。 そのため、NTLM を認証プロトコルとして使用する場合、クライアントは適切なサービスと通信していることを確認できません。
クライアント資格情報または無効な ID を指定すると、NTLM の使用が強制されます
クライアントを作成するときに、ドメイン名を指定せずにクライアント資格情報を指定するか、無効なサーバー ID を指定すると、Kerberos プロトコルの代わりに NTLM が使用されます ( AllowNtlm プロパティが true に設定されている場合)。 NTLM はサーバー認証を行わないので、情報が公開される可能性があります。
たとえば、次の Visual C# コードに示すように、ドメイン名なしで Windows クライアントの資格情報を指定できます。
MyChannelFactory.Credentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password");
このコードではドメイン名が指定されていないため、NTLM が使用されます。
ドメインが指定されていても、エンドポイント ID 機能を使用して無効なサービス プリンシパル名が指定されている場合は、NTLM が使用されます。 エンドポイント ID の指定方法の詳細については、「 サービス ID と認証」を参照してください。