信息泄露使攻击者能够获取有关系统的重要信息。 因此，请始终考虑要透露的信息以及恶意用户是否可以使用它。 下面列出了可能的信息泄露攻击，并为每个攻击提供缓解措施。
消息安全和 HTTP
如果通过 HTTP 传输层使用消息级安全性，请注意消息级安全性不会保护 HTTP 标头。 保护 HTTP 标头的唯一方法是使用 HTTPS 传输而不是 HTTP。 HTTPS 传输会导致整个消息（包括 HTTP 标头）使用安全套接字层 （SSL） 协议进行加密。
策略信息
保持策略安全是十分重要的，在联合方案中尤其如此 — 在这些方案中，会在策略中公开敏感的已颁发令牌要求或令牌颁发者信息。 在这些情况下，建议保护联合服务的策略终结点，以防止攻击者获取有关服务的信息，例如在颁发的令牌中放置的声明类型，或将客户端重定向到恶意令牌颁发者。 例如，攻击者可能通过将联合信任链重新配置为终止于执行中间人攻击的颁发者处，来发现用户名/密码对。 此外，建议联合客户端在通过策略检索获取绑定后，验证他们是否信任所获取的联合信任链中的颁发者。 有关联合方案的详细信息，请参阅 联合。
内存转储可能泄露声明信息
应用程序发生故障时，日志文件（如 Watson 博士生成的日志文件）可以包含声明信息。 不应将此信息导出给其他实体，例如支持团队，否则可能会导出包含私人数据的索赔信息。 可以通过不将日志文件发送到未知实体来缓解此问题。
终结点地址
终结点地址包含与终结点通信所需的信息。 SOAP 安全性必须在交换的安全协商消息中完整包含地址，才能在客户端和服务器之间协商对称密钥。 由于安全协商是启动过程，因此在此过程中无法加密地址标头。 因此，地址不应包含任何机密数据;否则，它会导致信息泄露攻击。
未加密传输的证书
使用 X.509 证书对客户端进行身份验证时，证书在 SOAP 标头中被明文传输。 请注意，这是潜在的个人身份信息（PII）披露。 对于TransportWithMessageCredential模式，这不是一个问题，因为整个消息都使用传输级安全性进行加密。
服务引用
服务引用是对另一个服务的引用。 例如，服务可能会在作过程中将服务引用传递给客户端。 服务引用还与 信任标识验证程序一起使用，这是一个内部组件，用于确保在向目标披露应用程序数据或凭据等信息之前确保目标主体的标识。 如果远程信任标识无法验证或不正确，则发送方应确保未披露任何可能危及自身、应用程序或用户的数据。
缓解措施包括：
假定服务引用是值得信任的。 请小心，确保在传输服务引用实例时这些实例未被篡改。
某些应用程序可以提供用户体验，该体验允许基于服务引用中的数据和远程主机证明的信任数据进行交互式建立信任。 WCF 为此类设施提供扩展点，但用户必须实现它们。
NTLM
默认情况下，在 Windows 域环境中，Windows 身份验证使用 Kerberos 协议对用户进行身份验证和授权。 如果 Kerberos 协议不能出于某种原因使用，则 NT LAN 管理器（NTLM）将用作回退。 可以通过将 AllowNtlm 属性设置为 false. 来禁用此行为。 允许 NTLM 时要注意的问题包括：
NTLM 公开客户端用户名。 如果需要保密用户名，请将绑定上的属性设置为
AllowNTLMfalse。NTLM 不提供服务器身份验证。 因此，当使用 NTLM 作为身份验证协议时，客户端无法确保它与正确的服务通信。
指定客户端凭据或无效标识会强制使用 NTLM
创建客户端时，指定没有域名的客户端凭据或指定无效的服务器标识，会导致使用 NTLM 而不是 Kerberos 协议（如果 AllowNtlm 属性设置为 true）。 由于 NTLM 不执行服务器身份验证，因此可能会披露信息。
例如，可以指定没有域名的 Windows 客户端凭据，如以下 Visual C# 代码所示。
MyChannelFactory.Credentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password");
该代码未指定域名，因此将使用 NTLM。
如果指定了域，但使用终结点标识功能指定了无效的服务主体名称，则会使用 NTLM。 有关如何指定终结点标识的详细信息，请参阅 服务标识和身份验证。