利用ASP.NET的内置功能抵御Web攻击

这种攻击有多危险？很难讲。这要取决于 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的朋友 Jeff Prosise 为 MSDN Magazine 写了一篇很好的关于会话劫持的文章。他的结论并不令人安慰：几乎不可能建立能够完全抵御依靠偷来的会话 ID Cookie 所发起的攻击的防御工事。但是他开发的代码为进一步提升安全标准提供了非常明智的建议。Jeff 创建了一个 HTTP 模块，该模块为会话 ID Cookie 监视传入的请求和传出的响应。该模块将一条哈希代码附加到会话 ID 之后，使攻击者重用 cookie 更为困难。您可以在此处阅读详情。

EnableViewStateMac

视图状态用于在对同一个页的两个连续请求之间保持控件的状态。默认情况下，视图状态是 Base64 编码的，并使用一个哈希值签名，以防止篡改。除非更改默认的页设置，否则不可能篡改视图状态。如果攻击者修改了视图状态，甚至使用正确的算法重新生成了视图状态，ASP.NET 都会捕获这些尝试并引

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!