表单身份验证是否可以防止会话劫持？

Question

我有使用Forms身份验证的ASP.NET MVC应用程序。用户通过身份验证后，作为响应，他将收到包含身份验证信息的表单cookie。现在关于表单cookie：它由机器密钥加密，并且通过签名保护其免受篡改。我也使用HTTPS ...但是，如果我以某种方式获取cookie并尝试从另一个客户端发出请求（意味着请求将来自另一个IP地址），该怎么办？

在我看来，这种情况会起作用。有没有办法防御这种攻击？

Answer 1

如果您在站点上的任何地方使用HTTPS，并在web.config中的system.web / authentication / forms元素上设置requireSSL =“true”，则表明浏览器仅通过HTTPS连接传回该cookie。这将防止绝大多数基于流量嗅探的会话劫持攻击，如果您的站点仅为HTTPS，则应该使用它。

表单身份验证本质上是无状态的。服务器正在加密以下信息并将其存储在客户端：CookiePath，Expiration，Expired，IsPersistent，IssueDate，Name，UserData，Version。假设您的machineKey尚未泄露，客户端只会将其视为一团加密数据。当它再次向服务器提供该blob时，服务器将其解密并将其转换回FormsAuthenticationTicket，根据配置验证故障单中的字段，验证故障单是否已过期等，并决定是否将请求视为认证。它不会“记住”关于哪些门票未完成的任何信息。另请注意，它不包含任何地址的IP地址。

我能想到的唯一真正的攻击向量，如果你只是HTTPS，请注意保护你的machineKey，并将表单auth cookie设置为requireSSL，攻击者将攻击客户端的浏览器和/或计算机。从理论上讲，他们可以将内存或磁盘中的cookie从浏览器空间中窃取出来。病毒/木马可能会这样做，甚至可能是恶意浏览器扩展。简而言之，如果用户可以获得有效的，未过期的Forms Auth cookie，他们可以从他们想要的任何机器上呈现它，直到它过期。您可以通过不允许持久的身份验证cookie并将时间保持在最低限度来降低风险。

如果他们有machineKey，他们可以随时从头开始创建FormsAuth cookie。

哦，不能忘记Heartbleed。如果您有使用不安全版OpenSSL的负载均衡器或反向代理，则攻击者可能会破坏您的私钥并通过HTTPS连接拦截流量。 ASP.NET不使用OpenSSL，因此在纯MS堆栈中您可以安全地使用它。如果您听说过MS的SSL实施中的漏洞，您需要尽快修补它并更改密码并重新颁发证书。

如果您担心基于浏览器/机器的劫持，您可能需要查看我开始[并放弃]的项目Sholo.Web.Security（https://github.com/scottt732/SholoWebSecurity）。它的目标是通过维护服务器上的状态来加强表单身份验证，代价是每个请求都有一些开销。您可以执行诸如撤销服务器端票证（踢/退出用户）以及阻止用户在IP地址之间移动票证等操作。它可能会在Wiktor描述的移动用户场景中变得烦人（它是可选的）。随意分叉或提交拉取请求。

Oleg引用的Anti-CSRF功能适用于启动登录过程的UI /表单机制，但据我所知，表单身份验证过程本身没有任何与CSRF相关的内容。也就是说，一旦cookie被发布给客户端，唯一保护它免于在服务器之间反弹的事实是cookie被限制为它们被发布的域/子域。您的stackoverflow.com cookie不会出现在serverfault.com上。浏览器会为您处理这些内容。

Answer 2

  

有没有办法抵御这种攻击？

你不应该。多年前我们已经实现了这样的功能并很快放弃了。事实证明：

• 单个用户从同一个浏览器/机器发出请求，但有时可以从不同的IP地址看到http / https之间切换
• 当她的手机在BTS之间切换时，单个用户旅行并使用她的手机有时会从不同的IP地址发出连续请求

Answer 3

为了澄清术语，会话劫持通常是指未经授权的用户访问服务器上的会话状态的漏洞。

身份验证Cookie与会话Cookie不同。 ASP.NET在保护身份验证cookie方面采取了更多的预防措施。您所描述的内容更好地用术语CSRF（跨站点请求伪造）来描述。正如@Wiktor在回复中指出的那样，限制IP访问是不切实际的。另外，如果您了解CSRF的工作原理，那么该漏洞可以在用户浏览器中从原始IP地址运行。

好消息是ASP.NET MVC已经内置了对CSRF预防的支持，这很容易实现。阅读here。