窗体身份验证是否可以防止会话劫持？

Question

我有使用窗体身份验证的ASP.NET应用程序。用户通过身份验证后，将收到包含身份验证信息的表单cookie作为响应。现在关于表单cookie:它由机器密钥加密，并通过签名防止篡改。我也使用HTTPS。但是，如果我以某种方式获得cookie并尝试从另一个客户端发出请求(这意味着该请求将从另一个IP地址发出)，该怎么办？

在我看来，这个方案是可行的。有什么方法可以防御这种攻击吗？

Answer 1

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

窗体身份验证本质上是无状态的。服务器正在加密以下信息并将其存储在客户端: CookiePath、过期、过期、IsPersistent、IssueDate、名称、UserData、版本。假设您的machineKey没有被攻破，客户端只会将其视为加密数据的blob。当它再次向服务器呈现该blob时，服务器会对其进行解密并将其转换回FormsAuthenticationTicket，根据配置验证票证中的字段，验证票证是否过期，等等，并决定是否将请求视为经过身份验证。它不会“记住”任何关于哪些门票是未完成的。还要注意的是，它没有包含任何地方的IP地址。

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

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

哦..。不能忘记心血。如果您的负载均衡器或反向代理使用的是不安全的OpenSSL版本，则攻击者可能会泄露您的私钥并截获HTTPS连接上的流量。ASP.NET不使用OpenSSL，所以在纯MS堆栈中不会出现这种情况。如果你听到任何关于微软SSL实现中的漏洞的消息，你会希望尽快修补它，修改你的密码并重新颁发证书。

如果你关心基于浏览器/机器的劫持，你可能想看看我开始并放弃的一个叫做Sholo.Web.Security (https://github.com/scottt732/SholoWebSecurity)的项目。它的目标是通过维护服务器上的状态来加强Forms身份验证，但代价是每次请求都会产生一些开销。您可以在服务器端执行诸如撤销票证之类的操作(踢出用户)，并防止用户在IP地址之间移动票证。在Wiktor描述的移动移动用户场景中(这是可选的)，它可能会很烦人。请随时派生或提交拉取请求。

Anti-CSRF功能指的是应用于启动登录过程的UI/form机制，但据我所知，Forms身份验证过程本身与CSRF无关。也就是说，一旦cookie被发布到客户端，保护它不被服务器之间反弹的唯一事情就是cookie被限制到它们被发布的域/子域的事实。您的stackoverflow.com cookies将不会显示给serverfault.com。浏览器会为你处理这些事情。

Answer 2

有什么方法可以防御这种攻击吗？

你不应该这么做。几年前我们就已经实现了这样的特性，但很快就放弃了。事实证明：

• 单个用户从完全相同的浏览器/计算机发出请求，但有时可以从不同的IP地址看到http/https之间的切换。
• 当单个用户的电话在BTSes

之间切换时，在旅行和使用她的移动电话时，有时会从不同的IP地址发出连续的请求

Answer 3

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

身份验证cookies不同于会话cookies。ASP.NET在保护身份验证cookies方面采取了更多的预防措施。使用术语CSRF (跨站点请求伪造)可以更好地描述您所描述的内容。正如@Wiktor在他的回复中指出的那样，通过IP限制访问是不切实际的。此外，如果您阅读了CSRF的工作原理，则可以从原始IP地址在用户浏览器中运行漏洞攻击。

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