利用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 攻击类型，以及应用程序中可能导致这些攻击得手的缺陷。 攻击 攻击的可能发起人 跨站点脚本 (XSS) 回显到页的不可信用户输入 SQL 注入 串连用户输入以形成 SQL 命令 会话劫持 会话 ID 猜测和失窃的会话 ID Cookie 一次单击 通过脚本发送的未被察觉的HTTP 张贴 隐藏域篡改 未检查（且受信）的隐藏域被填充以敏感数据 表 1. 常见的Web 攻击 列表中显现出来的关键性事实有哪些？在我看来，起码有以下三点： • 无论您何时将何种用户输入插入浏览器的标记中，您都潜在地将自己暴露在了代码注入攻击（任何 SQL 注入和 XSS 变种）之下。 • 必须以安全的方式实现数据库访问，就是说，应当为数据库使用尽可能少的权限，并通过角色来划分各个用户的职责。 • 永远都不通过网络发送敏感数据（更别说是明文了），并且必须以安全的方式将敏感数据存储在服务器上。 有意思的是，上面的三点分别针对的是 Web 安全性的三个不同方面，而这三个方面结合起来，才是唯一的一种生成防攻击、防篡改应用程序的合理方式。Web 安全性的各个层面可以总结如下： • 编码实践：数据验证、类型和缓冲区长度检查，防篡改措施 • 数据访问策略：使用决策来保护可能最弱的帐户，使用存储过程或者至少是参数化的命令。 • 有效的存储和管理：不将关键性数据发送到客户端，使用哈希代码来检测操作，对用户进行身份验证并保护标识，应用严格的密码策略 如您所看到的，只有可以通过开发人员、架构师和管理员的共同努力，才可以产生安全的应用程序。请不要假定您能够以其他方式达到同样目的。 编写 ASP.NET 应用程序时，您并不是独自面对黑客大军：唯一的武器是通过自己的大脑、技能和手指键入的代码行。ASP.NET 1.1 和更高版本都会施加援手，它们具有一些特定的功能，可以自动提高防御以上列出的某些威胁的屏障。下面我们对它们进行详细的检视。 ViewStateUserKey 从 ASP.NET 1.1 开始引入，ViewStateUserKey 是 Page 类的一个字符串属性，只有很少数开发人员真正熟悉该属性。为什么呢？让我们看看文档中是怎么说的。 在与当前页相关联的视图状态变量中将一个标识符分配给单个用户 除了有些累赘，这个句子的意思相当清楚；但是，您能老老实实地告诉我，它说明了该属性原本的用途吗？要理解 ViewStateUserKey的角色，您需要继续往下读，直到 Remarks 部分。 该属性有助于防止一次单击攻击，因为它提供了附 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
