我有使用表单例份验证的 ASP.NET MVC 应用程序。用户通过身份验证后，作为响应，他将收到包含身份验证信息的表单 cookie。现在关于表单 cookie:它由机器 key 加密，并通过签名防止篡改。我也使用 HTTPS...但是，如果我以某种方式获取 cookie 并尝试从另一个客户端发出请求(意味着该请求将从另一个 IP 地址发出)怎么办？
在我看来，这种情况是可行的。有什么方法可以防御这种攻击吗？
最佳答案
如果您在网站上的所有位置都使用 HTTPS，并在 web.config 中的 system.web/authentication/forms 元素上设置 requireSSL="true"，则您将指示浏览器仅通过 HTTPS 连接传回该 cookie。这将防止绝大多数基于流量嗅探的 session 劫持攻击，如果您的网站仅使用 HTTPS，那么您绝对应该使用它。
表单例份验证本质上是无状态的。服务器正在加密以下信息并将其存储在客户端:CookiePath、Expiration、Expired、IsPersistent、IssueDate、Name、UserData、Version。假设您的 machineKey 没有被泄露，客户端只会将其视为一团加密数据。当它再次将该 blob 呈现给服务器时，服务器将其解密并将其转换回 FormsAuthenticationTicket，根据配置验证票证中的字段，验证票证未过期等，并决定是否将请求视为已验证。它不会“记住”任何有关哪些票未清的信息。另请注意，它不包含任何地方的 IP 地址。
如果您仅使用 HTTPS，请注意保护您的 machineKey，并将表单例份验证 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 描述的旅行移动用户场景中，它可能会变得烦人(它是可选的)。请随意 fork 它或提交拉取请求。
0leg 所指的反 CSRF 功能适用于启动登录过程的 UI/表单机制，但据我所知，表单例份验证过程本身没有任何与 CSRF 相关的内容。也就是说，一旦 cookie 被发送到客户端，唯一能防止它在服务器之间被退回的就是 cookie 被限制在它们被发送的域/子域中。您的 stackoverflow.com cookie 不会呈现给 serverfault.com。浏览器会为您处理这些事情。
关于asp.net - 表单例份验证是否可以防止 session 劫持？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/23312397/