欢迎您访问我爱IT技术网，今天小编为你分享的编程技术是：【利用ASP.NET的内置功能抵御Web攻击】，下面是详细的分享！
利用ASP.NET的内置功能抵御Web攻击
ASP.NET开发人员应当始终坚持的做法
如果您正在阅读本文，可能就不需要再向您灌输Web应用程序中的安全性愈来愈重要这一事实了。您需要的可能是一些有关如何在ASP.NET应用程序中实现安全性的实际建议。坏消息是，没有任何开发平台—包括ASP.NET在内—能够保证一旦采用了该平台，您就能够编写百分百安全的代码。谁要是这么说，一准在撒谎。好消息是，就ASP.NET来说，ASP.NET，特别是版本1.1和即将发行的版本2.0，集成了一些便于使用的内置防御屏障。
光是应用所有这些功能并不足以保护Web应用程序，使其免受任何可能和可预见的攻击。但是，如果与其他防御技巧和安全策略相结合，内置的ASP.NET功能将可以构成一个强大的工具包，有助于确保应用程序在安全的环境中运行。
Web安全性是各种因素的总和，是一种范围远超单个应用程序的策略的结果，这种策略涉及数据库管理、网路配置，以及社会工程和phishing。
本文的目的在于说明ASP.NET开发人员为了将安全标准保持到合理的高度，所应始终坚持的做法。这也就是安全性最主要的内容：保持警惕，永不完全放松，让坏人越来越难以发起黑客攻击。
下面我们来看看ASP.NET提供了哪些可以简化这项工作的功能。
威胁的来源
在表1中，我汇总了最常见的Web攻击类型，以及应用程序中可能导致这些攻击得手的缺陷。
表1.常见的Web攻击
列表中显现出来的关键性事实有哪些？在我看来，起码有以下三点：
无论您何时将何种用户输入插入浏览器的标记中，您都潜在地将自己暴露在了代码注入攻击（任何SQL注入和XSS变种）之下。
必须以安全的方式实现数据库访问，就是说，应当为数据库使用尽可能少的权限，并通过角色来划分各个用户的职责。
永远都不通过网络发送敏感数据（更别说是明文了），并且必须以安全的方式将敏感数据存储在服务器上。
有意思的是，上面的三点分别针对的是Web安全性的三个不同方面，而这三个方面结合起来，才是唯一的一种生成防攻击、防篡改应用程序的合理方式。Web安全性的各个层面可以总结如下：
编码实践：数据验证、类型和缓冲区长度检查，防篡改措施
数据访问策略：使用决策来保护可能最弱的帐户，使用存储过程或者至少是参数化的命令。
有效的存储和管理：不将关键性数据发送到客户端，使用哈希代码来检测操作，对用户进行身份验证并保护标识，应用严格的密码策略
如您所看到的，只有可以通过开发人员、架构师和管理员的共同努力，才可以产生安全的应用程序。请不要假定您能够以其他方式达到同样目的。
编写ASP.NET应用程序时，您并不是独自面对黑客大军：唯一的武器是通过自己的大脑、技能和手指键入的代码行。ASP.NET1.1和更高版本都会施加援手，它们具有一些特定的功能，可以自动提高防御以上列出的某些威胁的屏障。下面我们对它们进行详细的检视。
ViewStateUserKey从ASP.NET1.1开始引入，ViewStateUserKey是Page类的一个字符串属性，只有很少数开发人员真正熟悉该属性。为什么呢？让我们看看文档中是怎么说的。
在与当前页相关联的视图状态变量中将一个标识符分配给单个用户
除了有些累赘，这个句子的意思相当清楚；但是，您能老老实实地告诉我，它说明了该属性原本的用途吗？要理解ViewStateUserKey的角色，您需要继续往下读，直到Remarks部分。
该属性有助于防止一次单击攻击，因为它提供了附加的输入以创建防止视图状态被篡改的哈希值。换句话说，ViewStateUserKey使得黑客使用客户端视图状态的内容来准备针对站点的恶意张贴困难了许多。可以为该属性分配任何非空的字符串，但最好是会话ID或用户的ID。为了更好地理解这个属性的重要性，下面我们简短介绍一下一次单击攻击的基本知识。
一次单击攻击包括将恶意的HTTP表单张贴到已知的、易受攻击的Web站点。之所以称为“一次单击”，是因为它通常是以受害者不经意的单击通过电子邮件发送的或者在拥挤的论坛中浏览时发现的诱惑性链接而开始的。通过点击该链接，用户无意中触发了一个远程进程，最终导致将恶意的<form>提交到一个站点。大家都坦白些吧：您真能告诉我，您从未因为好奇而单击过Clickheretowin$1,000,000这样的链接吗？显然，并没有什么糟糕的事情发生在您身上。让我们假定的确是这样的；您能说Web社区中的所有其他人都幸免于难了吗？谁知道呢。
要想成功，一次单击攻击需要特定的背景条件：
攻击者必须充分了解该有漏洞的站点。这是可能的，因为攻击者可以“勤奋地”研究该文件，或者他/她是一位愤怒的内部人员（例如，被解雇而又不诚实的雇员）。因此，这种攻击的后果可能是极其严重的。
站点必须是使用Cookie（如果是持续性Cookie，效果更好）来实现单次登录，而攻击者曾经收到过有效的身份验证cookie。
该站点的某些用户进行了敏感的事务。
攻击者必须能够访问目标页。
前已提及，攻击包括将恶意的HTTP表单提交到等待表单的页。可以推知，该页将使用张贴来的数据执行某些敏感操作。可想而知，攻击者清楚地了解如何使用各个域，并可以想出一些虚假的值来达到他的目的。这通常是目标特定的攻击，而且由于它所建立的三角关系，很难追本溯源—即黑客诱使受害者单击该黑客站点上的一个链接，而这又会导致恶意代码被张贴到第三个站点。（请参阅图1。）
为什么是不抱怀疑的受害者？这是因为，这种情况下，服务器日志中所显示的发出恶意请求的IP地址，是该受害者的IP地址。如前所述，这种工具并不像“经典”的XSS一样常见（和易于发起）；但是，它的性质决定了它的后果可能是灾难性。如何应对它？下面，我们审视一下这种攻击在ASP.NET环境下的工作机理。
除非操作编码在Page_Load事件中，否则ASP.NET页根本不可能在回发事件之外执行敏感代码。要使回发事件发生，视图状态域是必需的。请牢记，ASP.NET会检查请求的回发状态，并根据是否存在_VIEWSTATE输入域，相应地设置IsPostBack。因此，无论谁要向ASP.NET页发送虚假请求，都必须提供一个有效的视图状态域。
一次单击攻击要想得手，黑客必须能够访问该页。此时，有远见的黑客会在本地保存该页。这样，他/她就可以访问_VIEWSTATE域并使用该域，用旧的视图状态和其他域中的恶意值创建请求。问题是，这能行吗？
为什么不能？如果攻击者可以提供有效的身份验证cookie，黑客就可以进入，请求将被照常处理。服务器上根本不会检查视图状态内容（当EnableViewStataMac为off时），或者只会检查是否被篡改过。默认情况下，试图状态中没有机制可以将该内容与特定的用户关联起来。攻击者可以轻松地重用所获取的视图状态，冒充另一个用户合法地访问该页，以生成虚假请求。这正是ViewStateUserKey介入的地方。
如果选择准确，该属性可以将用户特定的信息添加到视图状态。处理请求时，ASP.NET会从视图状态中提取秘钥，并将其与正在运行的页的ViewStateUserKey进行比较。如果两者匹配，请求将被认为是合法的；否则将引发异常。对于该属性，什么值是有效的？
为所有用户将ViewStateUserKey设置为常量字符串，相当于将它保留为空。您必须将它设置为对各个用户都不同的值—用户ID，会话ID更好些。由于一些技术和社会原因，会话ID更为合适，因为会话ID不可预测，会超时失效，并且对于每个用户都是不同的。
以下是一些在您的所有页中都必不可少的代码：
为了避免重复编写这些代码，您可以将它们固定在从Page派生的类的OnInit虚拟方法中。（请注意，您必须在Page.Init事件中设置此属性。）
总体说来，使用基page类始终都不失为一件好事，我在BuildYourASP.NETPagesonaRicherBedrock一文中已经进行了说明。如果您要了解更多有关一次单击攻击者的伎俩的信息，可以在aspnetpro.com找到一篇非常好的文章。
Cookie和身份验证
Cookie之所以存在，是因为它们可以帮助开发人员达到一定目的。Cookie充当了浏览器与服务器之间的一种持续性链接。特别是对于使用单次登录的应用程序来说，失窃的cookie正是使得攻击成为可能的罪魁祸首。这对于一次单击攻击来说一点没错。
要使用Cookie，无需以编程方式显式创建和读取它们。如果您使用会话状态且实现表单身份验证，您会隐式地使用Cookie。当然，ASP.NET支持无cookie的会话状态，而且，ASP.NET2.0还引入了无cookie的表单身份验证。因此，理论上您可以在没有Cookie的情况下使用这些功能。我并不是说您不再必须这么做了，但事实上这正是疗法比疾病更糟的情形之一。无Cookie的会话，实际上将会话ID嵌入了URL中，这样谁都可以看到。
与使用Cookie有关的潜在问题有哪些？Cookie可能被盗（即被复制到黑客的计算机）和投毒（即被填充以恶意数据）。这些操作通常是即将发起的攻击的前奏。如果被盗，Cookie会“授权”外部用户以您的名义连接到应用程序（并使用受保护的页），这可能使黑客轻松地规避授权，并能够执行角色和安全设置所允许受害者执行的任何操作。因此，身份验证Cookie通常被赋予相对较短的生存期，即30分钟。（请注意，即使浏览器的会话完成所需的时间更长，cookie仍会过期。）发生失窃时，黑客有30分钟的时限来尝试攻击。
可以将这个时限加长，以免用户不得不过于频繁地登录；但请注意，这么做会将您自己置于危险境地。任何情况下，都应避免使用ASP.NET持续性Cookie。它将导致cookie具有几乎永久的生存期，最长可达50年！下面的代码片段演示了如何轻松修改cookie的过期日期。
您可以在自己的登录表单中使用这些代码来微调身份验证Cookie的生存期。
会话劫持
Cookie还被用于检索特定用户的会话状态。会话的ID被存储到cookie中，该cookie与请求一起来回传送，存储在浏览器的计算机上。同样，如果失窃，会话cookie将可被用来使黑客进入系统并访问别人的会话状态。不用说，只要指定的会话处于活动状态（通常不超20分钟），这就有可能发生。通过冒充的会话状态发起的攻击称为会话劫持。有关会话劫持的详细信息，请阅读TheftOnTheWeb:PreventSessionHijacking。
这种攻击有多危险？很难讲。这要取决于Web站点的功能，更为重要的是，该站点的页是如何设计的。例如，假定您能够获得别人的会话cookie，并将它附加到对站点上某个页的请求中。您加载该页并逐步研究它的普通用户界面。除了该页使用另一个用户的会话状态工作外，您无法将任何代码注入该页，也无法修改该页中的任何内容。这本身并不太坏，但是如果该会话中的信息是敏感和关键性的，就有可能直接导致黑客成功实现利用。黑客无法渗透到会话存储的内容中，但他可以使用其中存储的信息，就像自己是合法进入的一样。例如，假定有这样一个电子商务应用程序，它的用户在浏览站点时将物品添加到购物车中。
方案1。购物车的内容存储在会话状态中。但是，在结帐时，用户被要求通过安全的SSL连接确认和输入付款详细信息。这种情况下，通过接入其他用户的会话状态，黑客仅可以了解到一些有关受害者的购物喜好的细节。在这种环境下劫持实际上并不会导致任何损害。受威胁的只是保密性。
方案2。应用程序为每位注册用户处理一份档案，并将档案保存在会话状态中。糟糕的是，档案中（可能）包括信用卡信息。为什么要将用户档案详细信息存储到会话中？可能应用程序的其中一个目标是，从根本上避免使用户不得不重复键入自己的信用卡和银行信息。因此，在结算时，应用程序会将用户定位到一个具有预先填充的域的页。而有失谨慎的是，这些域的其中一个是从会话状态中获取的信用卡号。现在您可以猜到故事的结局了吗？
应用程序的页的设计，是防止会话劫持攻击的关键所在。当然，还有两点没有理清。第一点是，如何防止cookie盗窃？第二点是，ASP.NET可以如何检测和阻止劫持？
ASP.NET会话cookie极其简单，仅限于包含会话ID字符串本身。ASP.NET运行库从cookie中提取会话ID，并将其与活动的会话进行比较。如果ID有效，ASP.NET将连接到对应的会话并继续。这种行为极大地方便了已经偷到或者可以猜出有效的会话ID的黑客。
XSS和中间人(man-in-the-middle)攻击以及对客户端PC的强力访问，都是获取有效cookie的方法。为了防止盗窃，您应当实现安全最佳实践来防止XSS及其各变种得手。
而为了防止会话ID猜测，您应当干脆避免太高估计自己的技能。猜测会话ID意味着您知道如何预测有效的会话ID字符串。对于ASP.NET所使用的算法（15个随机数字，映射为启用URL的字符），随机猜测到有效ID的概率接近于零。我想不到任何理由来用自己的会话ID生成器替换默认的会话ID生成器。许多情况下，这么做只会为攻击者提供方便。
会话劫持更为糟糕的后果是一旦cookie被盗或者被猜出，ASP.NET并没有什么办法来检测欺诈性的cookie使用。同样，原因是ASP.NET将自己限制为检查ID的有效性，以及cookie的来源地。
我在Wintellect的朋友JeffProsise为MSDNMagazine写了一篇很好的关于会话劫持的文章。他的结论并不令人安慰：几乎不可能建立能够完全抵御依靠偷来的会话IDCookie所发起的攻击的防御工事。但是他开发的代码为进一步提升安全标准提供了非常明智的建议。Jeff创建了一个HTTP模块，该模块为会话IDCookie监视传入的请求和传出的响应。该模块将一条哈希代码附加到会话ID之后，使攻击者重用cookie更为困难。您可以在此处阅读详情。
EnableViewStateMac
视图状态用于在对同一个页的两个连续请求之间保持控件的状态。默认情况下，视图状态是Base64编码的，并使用一个哈希值签名，以防止篡改。除非更改默认的页设置，否则不可能篡改视图状态。如果攻击者修改了视图状态，甚至使用正确的算法重新生成了视图状态，ASP.NET都会捕获这些尝试并引发异常。视图状态被篡改并不一定有害，虽然它修改了服务器控件的状态—但可能成为造成严重感染的工具。因此，不移除默认情况下进行的计算机身份验证代码(MAC)交叉检查就异常重要。请参阅图2。
启用了MAC检查时（默认情况），将对序列化的视图状态附加一个哈希值，该值是使用某些服务器端值和视图状态用户秘钥（如果有）生成的。回发视图状态时，将使用新的服务器端值重新计算该哈希值，并将其与存储的值进行比较。如果两者匹配，则允许请求；否则将引发异常。即使假设黑客具有破解和重新生成视图状态的能力，他/她仍需要知道服务器存储的值才可以得出有效的哈希。具体说来，该黑客需要知道machine.config的<machineKey>项中引用的计算机秘钥。
默认情况下，项是自动生成的，以物理方式存储在WindowsLocalSecurityAuthority(LSA)中。仅在Web场（此时视图状态的计算机秘钥必须在所有的计算机上都相同）的情形下，您才应当在machine.config文件中将其指定为明文。
视图状态MAC检查是通过一个名为EnableViewStateMac的@Page指令属性控制的。如前所述，默认情况下，它被设置为true。请永远不要禁用它；否则将会使视图状态篡改一次单击攻击成为可能，并具有很高的成功概率。
ValidateRequest
跨站点脚本(XSS)对于很多经验丰富的Web开发人员来说是老朋友了，它在1999年左右就已经出现了。简单地说，XSS利用代码中的漏洞来将黑客的可执行代码引入另一个用户的浏览器会话中。如果被执行，注入的代码可以执行多种不同的操作—获取Cookie并将一个副本上载到黑客控制的Web站点，监视用户的Web会话并转发数据，修改被黑的页的行为和外观以使其提供错误的信息，甚至使自己变为持续性的，这样用户下一次返回该页时，欺诈代码会再次运行。请在TechNet文章Cross-siteScriptingOverview中详细阅读有关XSS攻击的基础知识。
代码中的哪些漏洞导致XSS攻击成为可能？
XSS利用的是动态生成HTML页、但并不验证回显到页的输入的Web应用程序。这里的输入是指查询字符串、Cookie和表单域的内容。如果这些内容在未经适当性能检查的情况下出现在网络上，就存在黑客对其进行操作以在客户端浏览器中执行恶意脚本的风险。（前面提到的一次单击攻击其实是XSS的一种新近变种。）典型的XSS攻击会导致不抱怀疑的用户点击一条诱惑性链接，而该链接中嵌入了转义的脚本代码。欺诈代码将被发送到一个存在漏洞且会毫不怀疑地输出它的页。以下是可能发生的情况的一个示例：
用户单击一个看上去明显安全的链接，最终导致将一些脚本代码传递到存在漏洞的页，这些代码首先获取用户计算机上的所有Cookie，然后将它们发送到黑客的Web站点。
请务必注意，XSS不是一个特定于供应商的问题，因此并不一定会利用InternetExplorer中的漏洞。它影响目前市场上的所有Web服务器和浏览器。更应注意的是，没有哪一个修补程序能够修复这一问题。您完全可以保护自己的页免受XSS攻击，方法是应用特定的措施和合理的编码实践。此外，请注意，攻击者并不需要用户单击链接就可以发起攻击。
要防御XSS，您必须从根本上确定哪些输入是有效的，然后拒绝所有其他输入。您可以在一本书中读到抵御XSS攻击的详细检查表，该书在Microsoft属于必读范围—WritingSecureCode，作者是MichaelHoward和DavidLeBlanc。特别地，我建议您仔细阅读第13章。
阻止阴险的XSS攻击的主要方法是向您的输入（任何类型的输入数据）添加一个设计合理、有效的验证层。例如，某些情况下即使是原本无害的颜色（RGB三色）也会将不受控制的脚本直接带入页中。
在ASP.NET1.1中，@Page指令上的ValidateRequest属性被打开后，将检查以确定用户没有在查询字符串、Cookie或表单域中发送有潜在危险性的HTML标记。如果检测到这种情况，将引发异常并中止该请求。该属性默认情况下是打开的；您无需进行任何操作就可以得到保护。如果您想允许HTML标记通过，必须主动禁用该属性。
ValidateRequest不是万能的药方，无法替代有效的验证层。请阅读此处以获取大量有关该功能的基础原理的宝贵信息。它基本上通过应用一个正则表达式来捕获一些可能有害的序列。
注ValidateRequest功能原本是有缺陷的，因此您需要应用一个修补程序它才能按预期工作。这样的重要信息常常不为人们所注意。奇怪的是，我发现我的其中一台计算机仍受该缺陷的影响。试试看！
没有任何关闭ValidateRequest的理由。您可以禁用它，但必须有非常好的理由；其中一条这样的理由可能是用户需要能够将某些HTML张贴到站点，以便得到更好的格式设置选项。这种情况下，您应当限制所允许的HTML标记（<pre>、<b>、<i>、<p>、<br>、<hr>）的数目，并编写一个正则表达式，以确保不会允许或接受任何其他内容。
以下是一些有助于防止ASP.NET遭受XSS攻击的其他提示：
使用HttpUtility.HtmlEncode将危险的符号转换为它们的HTML表示形式。
使用双引号而不是单引号，这是因为HTML编码仅转义双引号。
强制一个代码页以限制可以使用的字符数。
总之，使用但是不要完全信任ValidateRequest属性，不要太过懒惰。花些时间，从根本上理解XSS这样的安全威胁，并规划以一个关键点为中心的防御策略：所有的用户输入都是危险的。
数据库角度
SQL注入是另一种广为人知的攻击类型，它利用的是使用未筛选的用户输入来形成数据库命令的应用程序。如果应用程序兴高采烈地使用用户键入表单域中的内容来创建SQL命令字符串，就会将您暴露在这一风险下：恶意用户只需访问该页并输入欺诈参数，就可以修改查询的性质。您可以在此处了解更多有关SQL注入的信息。
要阻止SQL注入攻击，有许多方法。以下介绍最常见的技巧。
确保用户输入属于适当的类型，并遵循预期的模式（邮政编码、身份证号，电子邮件等）。如果预期来自文本框的数字，请在用户输入无法转换为数字的内容时阻止该请求。
使用参数化的查询，使用存储过程更好。
使用SQLServer权限来限制各个用户可以对数据库执行的操作。例如，您可能需要禁用xp_cmdshell或者将该操作的权限仅限于管理员。
如果使用存储过程，可以显著降低发生这种攻击的可能性。实际上，有了存储过程，您就无需动态地撰写SQL字符串。此外，SQLServer中将验证所有参数是否具有指定的类型。虽然光是这些并不是百分百安全的技巧，但是加上验证的话，将足以提高安全性。
更为重要的是，应确保只有经过授权的用户才能够执行可能具有严重后果的操作，如删除表。这要求认真仔细地设计应用程序的中间层。好的技巧（不光是为了安全性）应把焦点集中在角色上。应当将用户分组为各种角色，并为各个角色定义一个包含一组最少的权限的帐户。
几周前，WintellectWeb站点受到一种很复杂的SQL注入的攻击。那位黑客试图创建并启动一个FTP脚本来下载一个可能是恶意的可执行程序。幸运的是，这次攻击失败了。或者，其实是强用户验证，使用存储过程和使用SQLServer权限，导致了攻击未能成功？
总而言之，您应当遵循这些指南，以避免被注入有害的SQL代码：
使用尽可能少的权限运行，永远不以“sa”身份执行代码。
将访问限制给内置的存储过程。
首选使用SQL参数化查询。
不通过字符串串连来生成语句，不回显数据库错误。
隐藏域
在传统的ASP中，隐藏域是唯一一种在请求之间保持数据的方法。您需要在下一个请求中检索的任何数据都被打包到隐藏的<input>域中，并执行回程。如果有人在客户端上修改了该域中存储的值，会怎样？只要文本是明文的，服务器端环境就无法测知这一情况。ASP.NET中，页和各个控件的ViewState属性有两个用途。一方面，ViewState是跨请求保持状态的方法；另一方面，ViewState使您能够在受保护的、不易篡改的隐藏域中存储自定义值。
如图2所示，视图状态被附加了一个哈希值，对于每条请求，都会检查该值，以检测是否发生了篡改。除少数几种情况外，没有任何理由要在ASP.NET中使用隐藏域。视图状态能够以安全得多的方式实现相同的功能。前面开门见山地讲到过，在明文的隐藏域中存储敏感的值（如价格或信用卡详细信息），相当于对黑客张开大门；视图状态甚至能够使这种不好的做法比以前更为安全，因为视图状态具有数据保护机制。但是，请牢记，视图状态可以防止篡改，但是并不能保证保密性，除非使用加密—存储在视图状态中的信用卡详细信息无论如何都有风险。
在ASP.NET中，哪些情况下使用隐藏域是可接受的？当您生成需要将数据发送回服务器的自定义控件时。例如，假定您要创建一个支持重派列顺序的新DataGrid控件。您需要在回发中将新的顺序发送回服务器。如果不将这些信息存储到隐藏域中，又可以存储到哪里？
如果隐藏域为读/写域，即预期客户端会写入它，没什么办法能够完全制止黑客攻击。您可以尝试哈希或者加密该文本，但这并不能让您合理地确信不会遭受黑客攻击。此时，最好的防御就是让隐藏域包含惰性和无害的信息。
此外，应当注意ASP.NET公开了一个鲜为人知的类，可用于编码和哈希任何序列化的对象.该类为LosFormatter，ViewState实现用于创建回程到客户端的编码文本正是同一个类。
前面的代码片段演示了如何使用LosFormatter来创建类似视图状态的内容，对其编码并进行哈希。
电子邮件和垃圾邮件
在本文结尾，请让我指出，最常见的攻击中至少有两种（经典的XSS和一次单击）通常是通过诱使不抱怀疑的受害者单击诱惑性和欺骗性的链接来发起的。很多时候我们都可以在自己的收件箱中发现这样的链接，虽然有反垃圾邮件过滤器。几美元就可以买到大量电子邮件地址。用来生成这种列表的其中一种主要的技巧就是扫描Web站点上的公共页，查找并获取所有看上去像电子邮件的内容。
如果页上显示了电子邮件地址，很可能或早或晚这个地址都会被自动Web程序捕获。真的吗？当然，这要看该电子邮件是如何显示的。如果硬编码它，您输定了。如果采用其他表示形式（如dino-at-microsoft-dot-com），是否能够骗过自动Web程序不太清楚，但能让所有阅读您的页并想建立合法联系的人光火，倒是一定的。
总体说来，您应当确定一种方法，将电子邮件动态地生成为mailto链接。MarcoBellinaso编写的一个免费组件恰好可以完成这项工作。您可以从DotNet2TheMaxWeb站点获得该组件的全部源代码。
小结
有人怀疑Web可能是所有运行时环境中敌意最盛的吗？根源在于谁都可以访问Web站点，并尝试向它传递好的或坏的数据。但是，创建不接受用户输入的Web应用程序，又有什么意义呢？
我们还是直面现实吧：无论您的防火墙如何强大，无论您如何频繁地应用可用的修补程序，只要您运行的Web应用程序先天包含缺陷，攻击者迟早都可以通过主通道，也就是端口80，直接进入您的系统的最核心部分。
ASP.NET应用程序与其他Web应用程序相较，既不更易受攻击，也不更安全。安全性和漏洞同样根植于编码实践、实际经验和团队合作。如果网络不安全，那么任何应用程序都不安全；类似地，无论网络如何安全，管理如何精良，如果应用程序存在缺陷，攻击者总是能够得手。
ASP.NET的好处是提供了一些好的工具，只需少量工作，就可以将安全标准提升到可以接受的级别。当然，这并不是足够高的级别。不应纯粹以来ASP.NET的内置解决方案，同样也不应忽视它们。尽可能多地了解常见的攻击。
本文提供了内置功能的带注释的列表，以及一些有关攻击与防御的背景知识。用来检测传出的攻击的技巧是另一回事，可能需要一篇专门的文章来进行介绍。
以上所分享的是关于利用ASP.NET的内置功能抵御Web攻击，下面是编辑为你推荐的有价值的用户互动：
相关问题：ASP.NET WEB项目开发考试题，大家帮帮忙啊！！
答：你这个大概什么时候要？？说实话你这个项目用到的技术可是挺多的。不过这些我都做过。 >>详细
相关问题：ASP.NET7大内置对象以及对应功能？
答：ASP.NET的内置对象介绍 1.Response 2.Request 3.Server 4.Application 5.Session 6.Cookie Request对象主要是让服务器取得客户端浏览器的一些数据,包括从HTML表单用Post或者GET方法传递的参数、Cookie和用户认证。因为Request对象是Page对象的成... >>详细
相关问题：ASP.NET中如何防范SQL注入式攻击
答：在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如： ⑴ 某个ASP.NET Web应用有一个登录页面，这个登录页面控制着用户是否有权访问... >>详细
- 评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）
-