返回页首cookie 还被用于检索特定用户的会话状态。会话的 ID 被存储到 cookie 中，该 cookie 与请求一起来回传送，存储在浏览器的计算机上。同样，如果失窃，会话 cookie 将可被用来使黑客进入系统并访问别人的会话状态。不用说，只要指定的会话处于活动状态（通常不超 20 分钟），这就有可能发生。通过冒充的会话状态发起的攻击称为会话劫持。有关会话劫持的详细信息，请阅读 Theft On The Web: Prevent Session Hijacking。
这种攻击有多危险？很难讲。这要取决于 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 Coo
