如果 web.config 中 configuration/system.web/authentication/forms 元素的 cacheRolesInCookie 属性设置为 true，则每个用户的角色都将缓存在 Cookie 中。如果采用明文形式存储此信息，任何有权访问应用程序交互所使用的计算机的用户都能访问 Cookie 中存储的信息。更糟糕的是，如果允许攻击者任意修改 Cookie 中存储的数据，他们将可以篡改提供给应用程序的信息，还可能更改应用程序行为谋利。

在许多情况下，应用程序可根据使用它的上下文以编程方式验证来自 Cookie 的输入，但 ASP.NET 验证框架提供了一种确认 Cookie 未被意外修改的绝佳方法。如果没有这种方法，将很难且通常不可能以高度可信的方式确定所有输入都经过验证。

ASP.NET Web 服务通过自动生成描述如何与 Web 服务通信的文档来加快 Web 服务客户端的开发。

当收到浏览器请求时，启用了文档协议的 Web 服务将生成 HTML 格式的页面。

此 HTML 格式的页面描述以下信息：
1.支持的操作
2.每个操作接受的参数
3.应该在这些参数中传递的数据类型

该文档协议还生成一个 XML 格式的 Web 服务描述语言 (WSDL) 文件。此文件旨在让应用程序了解如何构建对 Web 服务的请求。此信息对开发人员非常有用，尤其是为公共 Web 服务创建客户端的开发人员。但是，显示有关专用 Web 服务功能的详细信息会增加恶意攻击者滥用 Web 服务的风险。文档协议始终描述 Web 服务的所有函数和参数，即使只有这些函数的子集可供公开访问。

ASP .NET 应用程序应配置为使用自定义错误页面而不是框架默认页面。默认错误页面提供有关所发生错误的详细信息，不应在生产环境中使用。<customErrors> 标签的 mode 属性定义是使用自定义还是默认错误页面。

攻击者可以利用默认错误页面提供的附加信息，对应用程序所用的框架、数据库或其他资源发动攻击。

默认情况下，ASP.NET 在解密有效负载（例如，ViewState、FormsAuth cookies 和 ScriptResource.axd URL）之前对加密签名进行内部验证，然后将这些值传递至应用程序进一步处理。但是，在解密有效负载之前，可以使用 aspnet:UseLegacyEncryption 设置修改此功能，禁用加密签名验证。这样，恶意客户端将可以解密、伪造或采用其他方式篡改加密数据。

示例 1：在以下示例中，aspnet:UseLegacyEncryption 设置为 true。

...
  <appSettings>
    <add key="aspnet:UseLegacyEncryption" value="true" />
  </appSettings>
...

ASP.NET 应用程序可以将用户名和密码对存储在 ASP.NET 应用程序 web.config 文件的 <credentials> 元素中，支持明文、MD5 和 SHA1 密码格式。

任何有权访问应用程序配置文件的用户都能访问采用明文的形式或使用弱加密算法存储的密码。其中可能包括托管应用程序的计算机或应用程序所在的源代码存储库。

示例 1：以下 web.config 条目采用明文的形式存储密码的方式有误。

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET 支持以三种格式存储的凭据密码，通过 configuration/system.web/authentication/forms/credentials 元素的 passwordFormat 属性指定。此属性可能的值包括：

Clear - 表示采用明文的形式存储密码（最不安全）
MD5 - 表示存储密码的 MD5 散列
SHA1- 表示存储密码的 SHA1 散列（最安全）

虽然 MD5 散列的安全性高于明文，但研究人员已发现针对 MD5 散列算法的强力攻击。目前，SHA1 散列仍可提供合理的保护来抵御此类攻击。

未经检查的输入是导致 ASP.NET 应用程序漏洞的主要原因。未经检查的输入会导致许多漏洞，包括 Cross-Site Scripting、Process Control 和 SQL Injection。

为防止此类攻击，请在应用程序处理所有程序输入之前，使用 ASP.NET 验证框架检查所有程序输入。

验证框架的示例用途框架包括进行检查以确保：

- 电话号码字段仅包含电话号码中的有效字符

- 布尔值仅为“T”或“F”

- 自由形式的字符串具有合理的长度和组成

如果 web.config 中 configuration/system.web/authentication/forms 元素的 cacheRolesInCookie 属性设置为 true，则每个用户的角色都将缓存在 Cookie 中。如果采用明文形式存储此信息，任何有权访问应用程序交互所使用的计算机的用户都能访问 Cookie 中存储的信息。更糟糕的是，如果允许攻击者任意修改 Cookie 中存储的数据，他们将可以篡改提供给应用程序的信息，还可能更改应用程序行为谋利。

在许多情况下，应用程序可根据使用它的上下文以编程方式验证来自 Cookie 的输入，但 ASP.NET 验证框架提供了一种确认 Cookie 未被意外修改的绝佳方法。如果没有这种方法，将很难且通常不可能以高度可信的方式确定所有输入都经过验证。