本页内容

本模块内容

Web 页和控件位于应用程序的防御前线，它们很容易受到蓄意破坏应用程序安全的攻击者的猛烈攻击。攻击者的最终目标一般是后端系统和数据存储。

像代码注入或跨站点脚本 (XSS) 这些成功的应用程序攻击都利用了服务器端应用程序漏洞。这些漏洞可造成破坏性的影响，并导致信息曝光、身份哄骗、权限提升及远程执行代码。要构建安全的 Web 页和控件，您必须遵照本模块讨论的正确编程方法。

模块首先列出并说明了常见的 ASP.NET 页和控件威胁及其相关对策，然后提供了一份必须解决的应用程序安全问题综合列表。表中包括了输入验证、输出编码、身份验证、授权、模拟、敏感数据保护、安全会话管理、参数处理保护和异常管理。这些技术都是深层安全解决方案的基本组成部分。但由于上述威胁常被忽视，无论基础结构如何安全，攻击者都能成功破坏您的系统。

目标

使用本模块可以实现：

适用范围

本模块适用于下列产品和技术：

如何使用本模块

除了后面介绍的安全编程方法之外，您还可以使用本指南的相应模块来辅助构建安全的 ASP.NET 网页和控件。

威胁和对策

大多数 Web 应用程序攻击都要在 HTTP 请求中传递恶意输入项。一般，这种攻击并非强迫应用程序执行未经授权的操作，而是要中断应用程序的正常操作。因此，全面验证输入内容是解决很多攻击的必要步骤。而且，在您开发 ASP.NET Web 页和控件时，必须赋予输入验证最高的优先级。常见威胁包括：

图 10.1 着重介绍了 Web 应用程序面临的常见威胁。

图 10.1
“ASP.NET Web 页和控件的常见威胁”

代码注入

如果攻击者使用您应用程序的安全上下文运行任意代码，则产生代码注入攻击。如果应用程序使用特权帐户运行，将增加系统受攻击的风险。

攻击

代码注入攻击有很多类型，具体包括：

安全漏洞

导致代码注入攻击成功的安全漏洞包括：

对策

防止代码注入可采取下列对策：

会话劫持

如果攻击者捕获了身份验证令牌并控制了其他用户的会话，则发生会话劫持现象。通常，身份验证令牌保存在 cookie 或 URL 中。如果攻击者捕获了身份验证令牌，他（或她）会将令牌连同请求一起传递给应用程序。应用程序则将该请求与合法用户会话相关联，这样，攻击者便得到了访问该应用程序受限内容（这些受限内容都要求验证访问身份）的权限。进而，攻击者便有了合法的用户身份和权限。

安全漏洞

致使 Web 页和控件遭受会话劫持攻击的常见安全漏洞包括：

攻击

会话劫持攻击包括：

对策

可采取下列对策防止会话劫持：

身份哄骗

如果恶意用户盗用合法用户的身份访问应用程序，则发生身份哄骗现象。

安全漏洞

致使 Web 页和控件遭受身份哄骗攻击的常见安全漏洞包括：

攻击

身份哄骗攻击包括：

对策

可采取下列对策防止身份哄骗：

有关在数据库中保存密码哈希值和其他机密的详细信息，请参阅模块 14 构建安全的数据访问。

参数处理

参数是网络中从客户端传递至服务器的一些数据。参数包括表单域、查询字符串、视图状态、cookie 和 HTTP 头。如果使用未经保护的参数传递敏感数据（或传递用于制定服务器安全决策的数据），应用程序可能有信息泄漏的危险，或遭受未授权的访问。

安全漏洞

可导致参数处理的安全漏洞包括：

攻击

参数处理攻击包括：

对策

可采取下列对策防止参数处理：

网络窃听

网络窃听涉及使用网络监视软件跟踪传递于浏览器和 Web 服务器之间的数据包。它可导致泄漏应用程序特定的机密数据、检索登录凭据或捕获身份验证 cookie。

安全漏洞

可导致网络窃听攻击成功的安全漏洞包括：

攻击

使用网络中的数据包嗅探 (sniff) 工具可实施网络窃听攻击，从而捕获网络数据流。

对策

要对抗网络窃听，请使用安全套接字层 (SSL) 在浏览器和 Web 服务器间建立加密通信通道。只要在网络中发送凭据、身份验证票证或敏感的应用程序数据，就一定要使用 SSL。

信息泄漏

如果攻击者通过探测 Web 页来找寻引起异常的各种情况，则出现消息泄漏攻击。对于攻击者而言，这是一种颇有成效的攻击方法。因为异常细节信息常以 HTML 的形式返回并显示在浏览器中。这可能会泄漏很有用的信息，如堆栈跟踪。堆栈跟踪包含数据库连接字符串、数据库名、数据库方案信息、SQL 语句以及操作系统和平台版本。

安全漏洞

可导致信息泄漏的安全漏洞包括：

攻击

可导致信息泄漏的攻击有多种，具体包括：

对策

可采取下列措施防止信息泄漏：

设计注意事项

开发 Web 页和控件之前，必须考虑很多重要问题。关键的注意事项如下：

使用服务器端输入验证

在设计时，请明确 Web 页和控件所处理的全部不同用户输入源。包括表单域、查询字符串、从 Web 用户处收到的 cookie 以及来自后端数据源的数据。很显然，Web 用户并不属于应用程序信任范畴，因此，您必须在服务器中验证来自该数据源的所有输入。除非绝对信任从后端数据源中检索的数据，否则请务必在将数据发送到客户端之前进行验证和净化。确保解决方案不依赖于客户端验证，因为客户端验证很容易被忽视。

对 Web 站点进行分区

Web 站点的设计必须区分公共访问部分和要求身份验证的受限部分。使用应用程序虚拟根目录下独立的子目录可维护各种受限的页面。例如，典型电子商务网站中的结帐功能要求验证访问者的身份来传递信用卡号等敏感数据。独立的子目录允许您应用附加的安全性（例如，通过要求 SSL），但不会给整个站点带来 SSL 性能负荷此外，它还允许您限制 HTTPS 连接中的身份验证 cookie 传递来缓解会话劫持风险。图 10.2 显示了一种典型的分区。

图 10.2
划分为公共区域和安全区域的 Web 站点

请注意，在图 10.2 中，受限的子文件夹使用 Internet 信息服务 (IIS) 配置，要求通过 SSL 访问。Web.config 中的第一个 <authorization> 元素允许所有用户访问公共区域，第二个元素禁止未经授权的用户访问安全子文件夹的内容并强制登录。

有关限制身份验证 cookie，使其只能通过 HTTPS 连接传递的详细信息，以及如何在受限和非受限页面间导航的详细信息，请参阅本模块身份验证部分的“使用绝对 URL 导航”。

考虑访问资源的身份

在默认情况下，ASP.NET 应用程序不模拟帐户，而是使用特权最低的 ASPNET 进程帐户运行 ASP.NET Web 应用程序来访问资源。默认值是使用推荐的配置。在很多情况下，您可能需要使用不同的 Windows 安全上下文访问资源，具体情况包括：

保护凭据和身份验证票证

您的设计必须考虑保护凭据和身份验证票证安全的方面。如果凭据是通过网络传递的，且位于永久存储（如配置文件）中，您必须保护这些凭据。由于身份验证票证容易遭受劫持攻击，必须确保票证在网络中的安全。加密即是一种解决方案。此外，您还可以使用 SSL 或 IPSec 来保护网络中的凭据和身份验证票证。DPAPI 是一种在配置文件中加密凭据的很好的解决方案。

安全地失败

如果应用程序出现难以恢复的异常情况，请确保应用程序安全地失败，不要造成系统完全对外部敞开的局面。防止对恶意用户而言重要的异常细节信息被传播给客户端，确保仅返回一般错误页。规划使用结构化的异常处理来处理错误，而不是依赖方法错误代码来处理错误。

考虑授权粒度

考虑您在站点身份验证中使用的授权粒度。如果目录的配置要求身份验证，是否所有的用户都有相等的权限来访问该目录中的页面？如果需要，可基于身份（或常用的调用者角色成员身份）为不同页面应用不同的授权规则。方法是，在不同的 <location> 元素中使用 <authorization> 元素。

例如，同一目录中的两个页面在 Web.config 文件中有不同的 <allow> 元素和 <deny> 元素。

将 Web 控件和用户控件置于独立的程序集中

如果将 Web 控件和用户控件置于各自的程序集中，可通过代码访问安全策略分别配置每个程序集的安全性。这为管理员提供了更多的灵活性。换言之，您不必仅为满足单个控件的需要而向所有控件授予扩展权限。

将资源访问代码置于独立的程序集中

使用独立的程序集，然后根据页类（非页类事件处理程序中的嵌入资源访问代码）来调用这些程序集。这可提升代码访问安全策略的灵活性，并对构建部分信任 Web 应用程序起着特别重要的作用。有关详细信息，请参阅模块 9 ASP.NET 代码访问安全性。

输入验证

如果对输入的类型、长度、格式和范围做出毫无根据的假设，应用程序可能失败。如果攻击者发现了您做出的毫无根据的假设，输入验证可能成为安全问题。此时，攻击者可能提供构思巧妙的输入，使您的应用程序受到一定的损害。在 Web 应用程序中，误信用户输入是最常见且最具破坏性的安全漏洞之一。

约束并净化

首先是限制输入内容，然后通过验证输入的类型、长度、格式和范围检查正确数据。有时，您可能还必须净化输入，从而确保可能的恶意输入的安全。例如，如果应用程序支持任意格式的输入字段（如注释字段），您可能要使用一些“安全”HTML 元素，如 <b> 和 <i>，然后放弃其他所有 HTML 元素。下表汇总了在约束和净化数据中可用的选项：

表 10.1：约束和净化数据的相关选项

正则表达式

您可以使用正则表达式限制有效字符的范围、放弃无用字符或执行长度和格式检查。您可以定义输入项必须匹配的模式来限制输入格式。ASP.NET 提供了 RegularExpressionValidator 控件，而 Regex 类位于 System.Text.RegularExpressions 命名空间。

如果使用验证程序控件，验证将在控件为空时成功。对于必填字段，请使用 RequiredFieldValidator。此外，客户端和服务器中实施的正则表达式验证可能略有不同。客户端使用的是 Microsoft Jscript 开发软件的正则表达式语法；而服务器使用的是 System.Text.RegularExpressions.Regex 语法。由于 JScript 正则表达式语法是 System.Text.RegularExpressions.Regex 语法的子集，因此建议使用 JScript 正则表达式语法，以便在客户端和服务器得到相同的结果。

有关 ASP.NET 验证程序控件的完整信息，请参阅 .NET Framework 文档。

RegularExpressionValidator 控件

要验证 Web 表单域的输入，您可以使用 RegularExpressionValidator 控件。请将该控件拖到 Web 表单中，然后设置 ValidationExpression、ControlToValidate 和 ErrorMessage 属性。

您可以使用 Microsoft Visual Studio® .NET 中的属性窗口设置验证表达式，也可以使用 Page_Load 事件处理程序动态设置属性。后者允许您将页面中所有控件的正则表达式集中分在一组。

Regex 类

如果在常规的 HTML 控件中不使用 runat="server" 属性（除了使用 RegularExpressionValidator 控件的情形），或需要验证来自其他源（像查询字符串或 cookie）中的输入，则可在页类或验证帮助程序方法中使用 Regex 类（可能在独立的程序集中）。本节稍后将给出一些示例。

正则表达式注释

如果使用下面的语法并使用表达式 # 对每个组件进行注释，则更容易了解正则表达式。要启用注释，还必须指定 RegexOptions.IgnorePatternWhitespace，它表明忽略非转义空格。

Regex regex = new Regex(@"
^           # 起始标记
(?=.*\d)     # 必须至少包含一个数字
(?=.*[a-z])  # 必须包含一个小写字母
(?=.*[A-Z])  # 必须包含一个大写字母
.{8,10}      # 字符长度从 8 到 10
$            # 结束标记，
RegexOptions.IgnorePatternWhitespace);

字符串字段

要验证字符串字段（如名称、地址和纳税辨识号等），请使用正则表达式执行下列操作：

名称

下面的示例说明了已在验证名称字段中使用的 RegularExpressionValidator 控件。

<form >
<asp:TextBox ></asp:TextBox>
<asp:RegularExpressionValidator  
ControlToValidate="txtName" 
ValidationExpression="^[a-zA-Z'.`-´\s]{1,40}$" 
ErrorMessage="Invalid name">
</asp:regularexpressionvalidator>
</form>

上述验证表达式在输入名称字段中限定使用字母字符（大小写均可）、一个名称省略符号（如 O'Dell）和点号。此外，字段长度不得超过 40 个字符。

社会保险号

下面的示例显示了为 RegularExpressionValidator 控件生成的 HTML 代码。该控件用于验证美国社会保险号表单域：

<form >
<asp:TextBox ></asp:TextBox>
<asp:RegularExpressionValidator  
ErrorMessage="Invalid social security number" 
ValidationExpression="\d{3}-\d{2}-\d{4}" 
ControlToValidate="txtSSN">
</asp:RegularExpressionValidator>
</form>

上述验证表达式是 Visual Studio .NET 的标准表达式之一。使用该表达式可验证给定输入字段的格式、类型和长度。输入格式必须是：三个数字 + 一个短划线；两个数字 + 一个短划线；或四个数字。

如果使用的不是服务器控件（除了验证程序控件），或需要验证来自表单域以外的源的输入，可在方法代码中使用 System.Text.RegularExpression.Regex 类。下面的示例说明了如何在页类中直接使用静态 Regex.IsMatch 方法而不使用验证程序控件来验证相同的字段：

if (!Regex.IsMatch(txtSSN.Text, @"^\d{3}-\d{2}-\d{4}$"))
{
// 社会保险号无效
}

日期字段

具有相同 .NET Framework 类型的输入字段可由 .NET Framework 类型系统来检查类型。例如，要验证日期，您可以在输入数据不兼容的情况下，将输入值转换成 System.DateTime 类型的变量，然后处理得到的所有格式异常，如下所述。

try
{
DateTime dt = DateTime.Parse(txtDate.Text).Date;
}
// 如果类型转换失败，将触发 FormatException
catch( FormatException ex )
{
// 将无效日期消息返回给调用者
}

除了检查格式和类型，您可能还需检查日期字段的范围。使用 DateTime 可轻松执行此项操作，如下所述。

// 为简单起见省略了异常处理
DateTime dt = DateTime.Parse(txtDate.Text).Date;
// 日期必须是今天或之前
if ( dt > DateTime.Now.Date )
throw new ArgumentException("Date must be in the past");

数字字段

如果需要验证数字数据（如年龄），请使用 int 类型检查类型。要将字符串输入转换成整数格式，可以使用 Int32.Parse 或 Convert.ToIn32，然后处理出现无效数据类型的所有 FormatException，如下所述。

try
{
int i = Int32.Parse(txtAge.Text);
  . . .
}
catch( FormatException)
{
 . . .
}

范围检查

有时，您需要验证输入数据是否都在预设的范围中。下面的代码使用了 ASP.NET 的 RangeValidator 控件将输入范围限制在 0 到 255 之间。此外，本例还使用了 RequiredFieldValidator。如果不使用 RequiredFieldValidator，其他验证程序控件将接受空输入。

<form >
<asp:TextBox ></asp:TextBox>
<asp:RequiredFieldValidator 
 
runat="server" 
ErrorMessage="Please enter a number between 0 and 255" 
ControlToValidate="txtNumber"
style="LEFT:10px; POSITION:absolute; TOP:47px" >
</asp:RequiredFieldValidator>
<asp:RangeValidator 
 
runat="server" 
ErrorMessage="Please enter a number between 0 and 255" 
ControlToValidate="TextBox1" 
Type="Integer" 
MinimumValue="0"
MaximumValue="255" 
style="LEFT:10px; POSITION:absolute; TOP:47px" >
</asp:RangeValidator>
<asp:Button  
runat="server" Text="Button"></asp:Button>
</form>

下面的示例说明了如何使用 Regex 类验证范围：

try
{
// 如果无效，转换将触发异常。
int i = Convert.ToInt32(sInput);
if ((0 <= i && i <= 255) == true)
  {
// 数据无效，请使用编号
  }
}
catch( FormatException )
{
  . . .
}

净化输入

净化的作用是确保可能有恶意目的的数据的安全。如果许可的输入范围不能保证输入安全，使用此方法非常有用。这包含了去除用户提供的字符串末尾的空值或转义值，以便系统将其视为文字。如果需要净化输入并转换或去除特定的输入字符，请使用 Regex.Replace。

注意：使用此方法可实施深层防御。请在开始时始终将输入限定在已知“安全”值集的范围内。

下面的代码去掉了一组可能不安全的字符，包括 <>\"'%;()&。

private string SanitizeInput(string input)
{
Regex badCharReplace = new Regex(@"^([<>""'%;()&])$");
string goodChars = badCharReplace.Replace(input, "");
return goodChars;
}

有关净化任意格式输入字段（如注释字段）的详细信息，请参阅本模块后的跨站点脚本中的“净化任意格式输入”。

验证 HTML 控件

如果不使用服务器控件（即有 runat="server" 属性的控件），而使用常规 HTML 控件，您不能使用 ASP.NET 验证程序控件。但可以在 Page_Load 事件处理程序中使用正则表达式来验证 Web 页的内容，如下所示。

using System.Text.RegularExpressions;
. . .
private void Page_Load(object sender, System.EventArgs e)
{
// 请注意，IsPostBack 仅适用于 
// 服务器形式（有 runat="server"）
if ( Request.RequestType == "POST" ) // 非服务器形式
  {
// 验证提供的电子邮件地址
if( !Regex.Match(Request.Form["email"], 
@"^\w+([-+.]\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*$",
RegexOptions.None).Success) 
    {
// 无效电子邮件地址
    }
// 验证提供的名称
if ( !RegEx.Match(Request.Form["name"],
@"^[A-Za-z'\- ]$",
RegexOptions.None).Success) 
    {
// 无效名称
    }
  }
}

验证用于访问数据的输入

如果基于用户输入来生成动态 SQL 查询，SQL 注入攻击可注入由数据库执行的恶意 SQL 命令。在典型的基于 Web 的数据访问中，可使用下列深层防御战略：

有关为数据访问使用参数及编写安全数据访问代码的详细信息，请参阅模块 14 构建安全的数据访问。

验证用于文件 I/O 的输入

通常，您应避免使编写的代码接受来自调用者的文件输入或路径输入。正确的做法是，在读取和编写数据时使用固定的文件名和位置。这可确保您的代码不会被用来强制访问任意文件。此外，还可确保代码不容易遭受规范化 Bug 的攻击。

如果确实要接受输入文件名，需面临两个主要挑战。首先，结果文件路径和名称是否是有效的文件系统名称？其次，路径是否在应用程序上下文中有效？例如，路径是否位于应用程序虚拟目录的根目录下？

要使文件名规范化，请使用 System.IO.Path.GetFullPath。要检查文件路径是否在应用程序上下文中有效，可使用 .NET 代码访问安全性向您的代码授予精确的 FileIOPermission，以便只能访问特定目录中的文件。有关详细信息，请参阅模块 7 构建安全的程序集中的“文件 I/O”部分和模块 8 代码访问安全的实践。

使用 MapPath

如果使用 MapPath 将提供的虚拟路径映射到服务器中的某一物理路径，请使用接受 bool 参数的 Request.MapPath 重载，以防止跨应用程序映射，如下所示：

try
{
string mappedPath = Request.MapPath( inputPath.Text, 
Request.ApplicationPath, false);
}
catch (HttpException)
{
// 尝试跨应用程序映射
}	

最终的 false 参数可防止跨应用程序映射。这意味着，用户不能成功提供包含“..”的路径来遍历应用程序虚拟目录层次结构的外部。任何执行该操作的企图都将造成 HttpException 异常类型。

注意：服务器控件可使用 Control.MapPathSecure 方法来读取文件。此方法要求代码访问安全策略授予调用代码以完全信任；否则将触发 HttpException。有关详细信息，请参阅 .NET Framework SDK 文档中的 Control.MapPathSecure。

常用正则表达式

Visual Studio .NET 提供了一组非常有用的正则表达式。要访问这些表达式，请在 Web 窗体中添加 RegularExpresssionValidator 控件，然后单击控件 Expression 属性字段中的省略号按钮。下表显示了另外几个在常用 Web 页字段中非常有用的表达式。

表 10.2：常用的正则表达式字段

跨站点脚本

XSS 攻击可通过注入客户端脚本代码来探测 Web 页验证中的漏洞。代码随后被送回信任用户，并由浏览器来执行。由于浏览器是从信任站点下载脚本代码的，因此不识别代码是否合法，Internet Explorer 安全区域不提供任何防御措施。此外，XSS 攻击还可通过 HTTP 或 HTTPS (SSL) 连接来起作用。最严重的探测情况是，攻击者编写脚本来检索提供信任站点访问权限的身份验证 cookie，然后将该 cookie 传递给攻击者已知的 Web 地址。这样，攻击者便盗用了合法用户的身份，从而非法获取网站的访问权限。

使用下列对策可防止 XSS 攻击：

验证输入

请使用本模块前面提到的各项技术来验证从应用程序信任范围以外接收到的任意输入的类型、长度、格式和范围。

编码输出

如果要编写 Web 页的文本输出，但不确信文本中是否包含 HTML 特殊字符（如 <、> 和 &），请确保使用 HttpUtility.HtmlEncode 方法对其进行预处理。即使文本来自于用户输入、数据库或本地文件，也必须这样做。同样，请使用 HttpUtility.UrlEncode 对 URL 字符串进行编码。

HtmlEncode 方法可将 HTML 中有特殊意义的字符替换为代表这些字符的 HTML 变量。例如，< 用 < 替换，" 用 " 替换。经过编码的数据不会令浏览器执行代码。实际上，数据是作为无害的 HTML 来显示的。

Response.Write(HttpUtility.HtmlEncode(Request.Form["name"]));

数据绑定控件

数据绑定 Web 控件不会对输出进行编码。唯一编码输出的控件是 TextBox 控件，而且 TextMode 属性要设置为 MultiLine。如果您将任意其他控件绑定在有恶意 XSS 代码的数据中，代码将在客户端中执行。因此，如果要从数据库中检索数据，但又不确信数据是否有效（可能由于数据库与其他应用程序共享），您必须在将数据传回客户端前对其进行编码。

净化任意格式的输入

如果 Web 页中有任意格式的文本框（如“注释”字段），而您希望在其中使用较安全的 HTML 元素（如 <b> 和 <i>），则可首先使用 HtmlEncode 进行预处理，然后有选择性地删除许可元素中的编码，从而实现安全处理的目的，如下所示：

StringBuilder sb = new StringBuilder( HttpUtility.HtmlEncode(userInput) ) ;
sb.Replace("<b>", "<b>");
sb.Replace("</b>", "</b>");
sb.Replace("<i>", "<i>");
sb.Replace("</i>", "</I>");
Response.Write(sb.ToString());

深层防御对策

除了前面提到的技术，您还可以使用下列深层防御对策来防止 XSS：

设置正确的字符编码

要成功限制在 Web 页中有效的数据，最重要的是限制输入数据的表示方式。这可防止恶意用户使用规范化和多字节转义序列来哄骗输入验证例程。

借助于 Web.config 中的 <globalization> 元素，ASP.NET 允许您指定页面级或应用程序级的字符集。下面介绍了这两种方法，二者均使用了 HTML 和 HTTP 早期版本中的默认 ISO-8859-1 字符编码。

要设置页面级字符编码，请使用 <meta> 元素或 ResponseEncoding 页面级属性，如下所示：

<meta http-equiv="Content Type" 
content="text/html; charset=ISO-8859-1" />

或

<% @ Page ResponseEncoding="ISO-8859-1" %>

要在 Web.config 中设置字符编码，请使用下面的配置：

<configuration>
<system.web>
<globalization 
requestEncoding="ISO-8859-1"
responseEncoding="ISO-8859-1"/>
</system.web>
</configuration>

验证 Unicode 字符

使用下面的代码可验证页面中的 Unicode 字符：

using System.Text.RegularExpressions;
. . .
private void Page_Load(object sender, System.EventArgs e)
{
// 名称的字母字符数必须介于 1 至 40 之间
// 还可在名称中使用（可选）特殊字符 '`´，例如，
// D'Angelo
if (!Regex.IsMatch(Request.Form["name"], @"^[\p{L}\p{Zs}\p{Lu}\p{Ll}]{1,40}$"))
throw new ArgumentException("Invalid name parameter");
// 使用单独的正则表达式来验证其他参数
  . . .
}

下面的内容说明了上述代码中的正则表达式：

使用 ASP.NET 的 validateRequest 选项

validateRequest 属性是 .NET Framework 版本 1.1 的特点之一。在默认情况下，该属性在 Machine.config 的 <pages> 元素中设置，且值为“True”。该属性要求 ASP.NET 检查从浏览器中接收的所有数据是否有潜在的恶意输入，例如包含 <script> 元素的输入。ASP.NET 可检查从 HTML 表单域、cookies 和查询字符串中接收的输入。.NET Framework 版本 1.0 不提供任何等价功能，但 IIS URLScan Internet 服务器应用程序编程接口 (ISAPI) 筛选器可执行类似工作。您还可以将该设置应用于每个使用 @ Page 标记的页面，如下所示：

<% @ Page validateRequest="True" %>

在 Web 服务器中安装 URLScan

URLScan 是一种运行 IISLockdown 工具时安装的 ISAPI 筛选器。它有助于缓解 XSS 攻击带来（通过注入潜在的恶意输入）的风险。有关 IISLockdown 和 URLScan 的详细信息，请参阅模块 16 保护 Web 服务器。

注意：Windows Server 2003 中的 IIS 6.0 有与 URLScan 相同的内置功能。

使用 HttpOnly Cookie 选项

Internet Explorer 6 Service Pack 1 支持新的 HttpOnly coo