可以将 ASP.NET W3Clogger.loggingFields 配置为允许记录敏感数据，例如私有信息和系统信息。
此数据可能包含与 HTTP 请求和 HTTP 响应相关的敏感信息，例如客户端/服务器 IP、服务器端口、标头 Cookie 以及经过验证的用于访问服务器的用户名。

如果发生数据泄露，攻击者可以利用此信息来执行以下操作：

- 窃取敏感信息或冒充具有更高权限的用户。
- 发现内部服务器，获得对受限资源的未授权访问权限。
- 设计专门针对对于检测到的服务器报告的已知漏洞的攻击


示例 1：以下代码显示了已禁用验证的控制器中的操作方法：

  builder.Services.AddW3CLogging(logging =>
    logging.LoggingFields = W3CLoggingFields.All;

    ... )

Example 1 显示如何使用标记 All 配置 W3Clogging，以记录 Http 请求所有可能的字段，包括敏感数据（如 ClientIpAddress、ServerName、ServerIpAddress、ServerPort、UserName 和 Cookie）。

FormsAuthentication.RedirectFromLoginPage() 方法会发布一个 authentication 票据，该票据使用户可以在一段时期内保留经过验证的身份。如果将该方法的第二参数设为 false，则调用该方法时会发布一个临时 authentication 票据，其有效期在 web.config 中配置。如果将第二参数设为 true，该方法就会发布一个 persistent authentication 票据。在 .NET 2.0 中，persistent authentication 票据的有效期就是在 web.config 中配置的值；但在 .NET 1.1 中，persistent authentication 票据的有效期有一个滑稽的默认值 - 50 年。

允许 persistent authentication 票据长时期存在会使用户和系统容易受到以下几种攻击：

对于注销失败的用户，身份验证票据漏洞延长了其暴露在会话劫持攻击下的时间。

持久身份验证票据增加了攻击者猜中正确的会话标识符的机率。

当攻击者成功地劫持了某个用户的会话后，该漏洞将使攻击者有更多的时间来盗取信息。

将 useUnsafeHeaderParsing 设置为 true 可放宽 HTTP 标头处理策略。HTTP 标头验证规则过于宽松可能导致易受攻击的应用程序受到各种攻击。



特别是，当此属性设置为 false 时，将不再强制执行以下验证规则：

在行尾代码中，使用 CRLF；不允许单独使用 CR 或 LF。

标头名称不应包含空格。

如果存在多个状态行，则将所有其他状态行视为格式错误的标头名称/值对。

除状态代码之外，状态行还必须包含状态描述。

标头名称不能包含非 ASCII 字符。无论此属性设置为 true 还是 false，都会执行此验证。

发生协议违规时，抛出 WebException 异常并将状态设置为 ServerProtocolViolation。如果 UseUnsafeHeaderParsing 属性设置为 true，则忽略验证错误。

将此属性设置为 true 存在安全隐患，因此只有在要求与服务器向后兼容时才能使用此设置。


示例 1：在以下示例中，useUnsafeHeaderParsing 会设置为 True。

...
<configuration>
   <system.net>
   <settings>
      <httpWebRequest  useUnsafeHeaderParsing="true" />
   </settings>
   </system.net>
</configuration>
...

在 ASP.NET 中，视图状态是一种在不同回发的 Web 表单中保持状态的机制。视图状态中存储的数据不可信，因为没有防范转发攻击的机制。当禁用视图状态消息身份验证检查时，信任视图状态尤其危险。禁用此检查相当于允许攻击者对视图状态中存储的数据进行任意更改，可能为攻击信任视图状态的代码敞开大门。攻击者可能会利用此类错误阻挠身份验证检查或更改项定价。

ASP.NET MVC 提供一种方便的方式（通过在表单端添加防伪标记并在控制器确认该防伪标记）来更好地保护应用程序以针对跨站点伪装请求。如果使用，该标记通常作为一个隐藏的表单字段并在表单提交时进行确认，这提高了请求是来自您的应用程序的可能性，而不是伪造的。

以下控制器代码不包括针对跨站点伪装请求的内置防范：

public ActionResult ActionName(Model model, string returnurl)
{
  // ... controller logic
}

ASP.NET MVC 提供一种方便的方式（通过在 HTML 表单添加防伪标记并在控制器确认该防伪标记）来更好地保护应用程序以针对跨站点伪装请求。如果使用，该标记通常作为一个隐藏的表单字段并在表单提交时进行确认，这提高了请求是来自您的应用程序的可能性，而不是伪造的。

通常，程序员应该包含该防伪标记，因为它增加了针对应用程序的恶意脚本的成本。

示例 1：以下 Razor 代码将在生成的 HTML 中创建一个表单，但未内置针对 Cross-Site Request Forgery 的防御措施：

@using (Html.BeginForm(new { ReturnUrl = ViewBag.ReturnUrl })) {
  // ... form elements
}

Example 2::The following Razor code creates a form in the resulting HTML without the built-in defense against cross-site request forgery. Note that parameter antiforgery is set to either false or null:

@using (Html.BeginForm("actionName", "controllerName", routeValues, FormMethod.Post, antiforgery: false, htmlAtts)) {
  // ... form elements
}

NSURLConnectionDelegate.connection(_:willSendRequestFor:) 代理方法允许代理立即就连接身份验证做出明智的选择。如果代理实施此方法，则无需实施 NSURLConnectionDelegate.connection(_:canAuthenticateAgainstProtectionSpace:) 或 NSURLConnectionDelegate.connection(_:didReceive:)。事实上，这些方法不会被调用，因此将忽略它们的所有安全检查。