启用了 MAC 检查时（默认情况），将对序列化的视图状态附加一个哈希值，该值是使用某些服务器端值和视图状态用户秘钥（如果有）生成的。回发视图状态时，将使用新的服务器端值重新计算该哈希值，并将其和存储的值进行比较。如果两者匹配，则允许请求；否则将引发异常。即使假设黑客具有破解和重新生成视图状态的能力，他/她仍需要知道服务器存储的值才能得出有效的哈希。具体说来，该黑客需要知道 machine.config 的 <machineKey > 项中引用的计算机秘钥。
ValidateRequest
跨站点脚本 (XSS) 对于非常多经验丰富的 Web 研发人员来说是老朋友了，他在 1999 年左右就已出现了。简单地说，XSS 利用代码中的漏洞来将黑客的可执行代码引入另一个用户的浏览器会话中。如果被执行，注入的代码能执行多种不同的操作 ? 获取 Cookie 并将一个副本上载到黑客控制的 Web 站点，监视用户的 Web 会话并转发数据，修改被黑的页的行为和外观以使其提供错误的信息，甚至使自己变为持续性的，这样用户下一次返回该页时，欺诈代码会再次运行。请在 TechNet 文章 Cross-site Scripting Overview 中周详阅读有关 XSS 攻击的基础知识。
代码中的哪些漏洞导致 XSS 攻击成为可能？
XSS 利用的是动态生成 HTML 页、但并不验证回显到页的输入的 Web 应用程式。这里的输入 是指查询字符串、Cookie 和表单域的内容。如果这些内容在未经适当性能检查的情况下出目前网络上，就存在黑客对其进行操作以在客户端浏览器中执行恶意脚本的风险。（前面提到的一次单击攻击其实是 XSS 的一种新近变种。）典型的 XSS 攻击会导致不抱怀疑的用户点击一条诱惑性链接，而该链接中嵌入了转义的脚本代码。欺诈代码将被发送到一个存在漏洞且会毫不怀疑地输出他的页。以下是可能发生的情况的一个示例：
Click to claim your prize
用户单击一个看上去明显安全的链接，最终导致将一些脚本代码传递到存在漏洞的页，这些代码首先获取用户计算机上的所有 Cookie，然后将他们发送到黑客的 Web 站点。
请务必注意，XSS 不是个特定于供给商的问题，因此并不一定会利用 Internet Explorer 中的漏洞。他影响目前市场上的所有 Web 服务器和浏览器。更应注意的是，没有哪一个修补程式能够修复这一问题。你完万能保护自己的页免受 XSS 攻击，方法是应用特定的措施和合理的编码实践。此外，请注意，攻击者并不必用户单击链接就能发起攻击。
要防御 XSS，你必须从根本上确定哪些输入是有效的，然后拒绝所有其他输入。你能在一本书中读到抵御 XSS 攻击的周详检查表，该书在 Microsoft 属于必读范围 ? Writing Secure Code ，作者是 Michael Howard 和 David LeBlanc。特别地，我建议你仔细阅读第 13 章。
阻止阴险的 XSS 攻击的主要方法是向你的输入（所有类型的输入数据）添加一个设计合理、有效的验证层。例如，某些情况下 即使是原本无害的颜色（RGB 三色）也会将不受控制的脚本直接带入页中。
在 ASP.NET 1.1 中，@Page 指令上的 ValidateRequest 属性被打开后，将检查以确定用户没有在查询字符串、Cookie 或表单域中发送有潜在危险性的 HTML 标记。如果检测到这种情况，将引发异常并中止该请求。该属性默认情况下是打开的；你无需进行所有操作就能得到保护。如果你想允许 HTML 标记通过，必须主动禁用该属性。
<%@ Page ValidateRequest="false" %>
ValidateRequest 不是 万能的药方，无法替代有效的验证层。请阅读此处 以获取大量有关该功能的基础原理的宝贵信息。他基本上通过应用一个正则表达式来捕捉一些可能有害的序列。
注 ValidateRequest 功能原本是有缺陷 的，因此你需要应用一个修补程式 他才能按预期工作。这样的重要信息常常不为人们所注意。奇怪的是，我发现我的其中一台计算机仍受该缺陷的影响。试试看！
没有所有关闭 ValidateRequest 的理由。你能禁用他，但必须有非常好的理由；其中一条这样的理由可能是用户需要能够将某些 HTML 张贴到站点，以便得到更好的格式设置选项。这种情况下，你应当限制所允许的 HTML 标记（
以下是一些有助于防止 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 中，隐藏域是唯一一种在请求之间保持数据的方法。你需要在下一个请求中检索的所有数据都被打包到隐藏的 ViewState 属性有两个用途。一方面，ViewState 是跨请求保持状态的方法；另一方面，ViewState 使你能够在受保护的、不易篡改的隐藏域中存储自定义值。
如图 2 所示，视图状态被附加了一个哈希值，对于每条请求，都会检查该值，以检测是否发生了篡改。除少数几种情况外，没有所有理由要在 ASP.NET 中使用隐藏域。视图状态能够以安全得多的方式实现相同的功能。前面开门见山地讲到过，在明文的隐藏域中存储敏感的值（如价格或信用卡周详信息），相当于对黑客张开大门；视图状态甚至能够使这种不好的做法比以前更为安全，因为视图状态具有数据保护机制。不过，请牢记，视图状态能防止篡改，不过并不能确保保密性，除非使用加密 ? 存储在视图状态中的信用卡周详信息无论怎么都有风险。
在 ASP.NET 中，哪些情况下使用隐藏域是可接受的？当你生成需要将数据发送回服务器的自定义控件时。例如，假定你要创建一个支持重派列顺序的新 DataGrid 控件。你需要在回发中将新的顺序发送回服务器。如果不将这些信息存储到隐藏域中，又能存储到哪里？
如果隐藏域为读/写域，即预期客户端会写入他，没什么办法能够完全制止黑客攻击。你能尝试哈希或加密该文本，但这并不能让你合理地确信不会遭受黑客攻击。此时，最佳的防御就是让隐藏域包含惰性和无害的信息。
此外，应当注意 ASP.NET 公开了一个鲜为人知的类，可用于编码和哈希所有序列化的对象.该类为 LosFormatter ，ViewState 实现用于创建回程到客户端的编码文本正是同一个类。
private string EncodeText(string text) {
StringWriter writer = new StringWriter();
LosFormatter formatter = new LosFormatter();
formatter.Serialize(writer, text);
return writer.ToString();
}
前面的代码片段演示了怎么使用 LosFormatter 来创建类似视图状态的内容，对其编码并进行哈希。
电子邮件和垃圾邮件
在本文结尾，请让我指出，最常见的攻击中至少有两种（经典的 XSS 和一次单击）通常是通过诱使不抱怀疑的受害者单击诱惑性和欺骗性的链接来发起的。非常多时候我们都能在自己的收件箱中发现这样的链接，虽然有反垃圾邮件过滤器。几美元就能买到大量电子邮件地址。用来生成这种列表的其中一种主要的技巧就是扫描 Web 站点上的公共页，查找并获取所有看上去像电子邮件的内容。
如果页上显示了电子邮件地址，非常可能或早或晚这个地址都会被自动 Web 程式捕捉。真的吗？当然，这要看该电子邮件是怎么显示的。如果硬编码他，你输定了。如果采用其他表示形式（如 dino-at-microsoft-dot-com ），是否能够骗过自动 Web 程式不太清晰，但能让所有阅读你的页并想建立合法联系的人光火，倒是一定的。
总体说来，你应当确定一种方法，将电子邮件动态地生成为 mailto 链接。Marco Bellinaso 编写的一个免费组件恰好能完成这项工作。你能从 DotNet2TheMax Web 站点获得该组件的全部原始码。
小结
有人怀疑 Web 可能是所有运行时环境中敌意最盛的吗？根源在于谁都能访问 Web 站点，并尝试向他传递好的或坏的数据。不过，创建不接受用户输入的 Web 应用程式，又有什么意义呢？
我们还是直面现实吧：无论你的防火墙怎么强大，无论你怎么频繁地应用可用的修补程式，只要你运行的 Web 应用程式先天包含缺陷，攻击者迟早都能通过主通道，也就是端口 80，直接进入你的系统的最核心部分。
ASP.NET 应用程式和其他 Web 应用程式相较，既不更易受攻击，也不更安全。安全性和漏洞同样根植于编码实践、实际经验和团队合作。如果网络不安全，那么所有应用程式都不安全；类似地，无论网络怎么安全，管理怎么精良，如果应用程式存在缺陷，攻击者总是能够得手。
ASP.NET 的好处是提供了一些好的工具，只需少量工作，就能将安全标准提升到能接受的级别。当然，这并不是 足够高的级别。不应纯粹以来 ASP.NET 的内置解决方案，同样也不应忽视他们。尽可能多地了解常见的攻击。
本文提供了内置功能的带注释的列表，及一些有关攻击和防御的背景知识。用来检测传出的攻击的技巧是另一回事，可能需要一篇专门的文章来进行介绍。
以上内容由 华夏名网 搜集整理，如转载请注明原文出处，并保留这一部分内容。
“华夏名网” http://www.sudu.cn 和 http://www.bigwww.com 是成都飞数科技有限公司的网络服务品牌，专业经营虚拟主机,域名注册，VPS,服务器租用业务。公司创建于2002年，经过6年的高速发展，“华夏名网”已经成为我国一家知名的互联网服务提供商，被国外权威机构webhosting.info评价为25大IDC服务商之一。
华夏名网网址导航: 虚拟主机 双线主机 主机 域名注册 cn域名 域名 服务器租用 酷睿服务器 vps vps主机
(阅读次数:103)
上一篇：
AS/400 LDAP用户帐号泄露漏洞 下一篇:
debian内核防毒AntiVir安装 （1）
[收藏 ] [评论 ] [打印本页 ] [返回上一页 ][关闭窗口 ]
当前位置:资讯中心主页 >安全工具 >文章内容