阻止阴险的 XSS 攻击的主要方法是向您的输入（任何类型的输入数据）添加一个设计合理、有效的验证层。例如，某些情况下即使是原本无害的颜色（RGB 三色）也会将不受控制的脚本直接带入页中。
在 ASP.NET 1.1 中，@Page 指令上的 ValidateRequest 属性被打开后，将检查以确定用户没有在查询字符串、Cookie 或表单域中发送有潜在危险性的 HTML 标记。如果检测到这种情况，将引发异常并中止该请求。该属性默认情况下是打开的；您无需进行任何操作就可以得到保护。如果您想允许 HTML 标记通过，必须主动禁用该属性。
＜%@ Page ValidateRequest="false" %>
ValidateRequest不是 万能的药方，无法替代有效的验证层。请阅读此处以获取大量有关该功能的基础原理的宝贵信息。它基本上通过应用一个正则表达式来捕获一些可能有害的序列。
注 ValidateRequest 功能原本是有缺陷的，因此您需要应用一个修补程序它才能按预期工作。这样的重要信息常常不为人们所注意。奇怪的是，我发现我的其中一台计算机仍受该缺陷的影响。试试看！
没有任何关闭 ValidateRequest 的理由。您可以禁用它，但必须有非常好的理由；其中一条这样的理由可能是用户需要能够将某些 HTML 张贴到站点，以便得到更好的格式设置选项。这种情况下，您应当限制所允许的 HTML 标记（＜pre>、＜b>、＜i>、＜p>、＜br>、＜hr>）的数目，并编写一个正则表达式，以确保不会允许或接受任何其他内容。
以下是一些有助于防止 ASP.NET 遭受 XSS 攻击的其他提示：
• 使用 HttpUtility.HtmlEncode 将危险的符号转换为它们的 HTML 表示形式。
• 使用双引号而不是单引号，这是因为 HTML 编码仅转义双引号。
• 强制一个代码页以限制可以使用的字符数。
总之，使用但是不要完全信任 ValidateRequest 属性，不要太过懒惰。花些时间，从根本上理解 XSS 这样的安全威胁，并规划以一个关键点为中心的防御策略：所有的用户输入都是危险的。
数据库角度
SQL 注入是另一种广为人知的攻击类型，它利用的是使用未筛选的用户输入来形成数据库命令的应用程序。如果应用程序兴高采烈地使用用户键入表单域中的内容来创建 SQL 命令字符串，就会将您暴露在这一风险下：恶意用户只需访问该页并输入欺诈参数，就可以修改查询的性质。您可以在此处了解更多有关 SQL 注入的信息。
要阻止 SQL 注入攻击，有许多方法。以下介绍最常见的技巧。
• 确保用户输入属于适当的类型，并遵循预期的模式（邮政编码、身份证号，电子邮件等）。如果预期来自文本框的数字，请在用户输入无法转换为数字的内容时阻止该请求。
• 使用参数化的查询，使用存储过程更好。
• 使用 SQL Server 权限来限制各个用户可以对数据库执行的操作。例如，您可能需要禁用 xp_cmdshell 或者将该操作的权限仅限于管理员。
如果使用存储过程，可以显著降低发生这种攻击的可能性。实际上，有了存储过程，您就无需动态地撰写 SQL 字符串。此外，SQL Server 中将验证所有参数是否具有指定的类型。虽然光是这些并不是百分百安全的技巧，但是加上验证的话，将足以提高安全性。
更为重要的是，应确保只有经过授权的用户才能够执行可能具有严重后果的操作，如删除表。这要求认真仔细地设计应用程序的中间层。好的技巧（不光是为了安全性）应把焦点集中在角色上。应当将用户分组为各种角色，并为各个角色定义一个包含一组最少的权限的帐户。
几周前，Wintellect Web 站点受到一种很复杂的 SQL 注入的攻击。那位黑客试图创建并启动一个 FTP 脚本来下载一个可能是恶意的可执行程序。幸运的是，这次攻击失败了。或者，其实是强用户验证，使用存储过程和使用 SQL Server 权限，导致了攻击未能成功？
总而言之，您应当遵循这些指南，以避免被注入有害的 SQL 代码：
• 使用尽可能少的权限运行，永远不以“sa”身份执行代码。
• 将访问限制给内置的存储过程。
• 首选使用 SQL 参数化查询。
• 不通过字符串串连来生成语句，不回显数据库错误。
返回页首
隐藏域
在传统的 ASP 中，隐藏域是唯一一种在请求之间保持数据的方法。您需要在下一个请求中检索的任何数据都被打包到隐藏的 ＜input> 域中，并执行回程。如果有人在客户端上修改了该域中存储的值，会怎样？只要文本是明文的，服务器端环境就无法测知这一情况。ASP.NET 中，页和各个控件的 ViewState 属性有两个用途。一方面，ViewState 是跨请求保持状态的方法；另一方面，ViewState 使您能够在受保护的、不易篡改的隐藏域中存储自定义值。
如图 2 所示，视图状态被附加了一个哈希值，对于每条请求，都会检查该值，以检测是否发生了篡改。除少数几种情况外，没有任何理由要在 ASP.NET 中使用隐藏域。视图状态能够以安全得多的方式实现相同的功能。前面开门见山地讲到过，在明文的隐藏域中存储敏感的值（如价格或信用卡详细信息），相当于对黑客张开大门；视图状态甚至能够使这种不好的做法比以前更为安全，因为视图状态具有数据保护机制。但是，请牢记，视图状态可以防止篡改，但是并不能保证保密性，除非使用加密 — 存储在视图状态中的信用卡详细信息无论如何都有风险。
在 ASP.NET 中，哪些情况下使用隐藏域是可接受的？当您生成需要将数据发送回服务器的自定义控件时。例如，假定您要创建一个支持重派列顺序的新 DataGrid 控件。您需要在回发中将新的顺序发送回服务器。如果不将这些信息存储到隐藏域中，又可以存储到哪里？
如果隐藏域为读/写域，即预期客户端会写入它，没什么办法能够完全制止黑客攻击。您可以尝试哈希或者加密该文本，但这并不能让您合理地确信不会遭受黑客攻击。此时，最好的防御就是让隐藏域包含惰性和无害的信息。
此外，应当注意 ASP.NET 公开了一个鲜为人知的类，可用于编码和哈希任何序列化的对象.该类为 LosFormatter，ViewState 实现用于创建回程到客户端的编码文本正是同一个类。
private string EncodeText(string text) {
StringWriter writer = new StringWriter();
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
