背景: 我在 tomcat 上部署了一个 javaee webapp，它使用基于表单的身份验证。当 Web 服务器收到登录请求时，它会将请求发送到专用的身份验证服务，以验证用户登录(用户 ID 和密码)。身份验证成功后，用户的 session 将保留在 Web 服务器中。
问题: 我写了一个简单的 webpp source code here , 来模拟场景。成功登录后，当前 HttpSession 实例将失效并创建新实例。对于登录后页面的每个请求，都会验证 session 。设置了一个新的 JSESSIONID cookie，用于在 session 期间识别用户，直到 session 过期或用户注销。这个 cookie 可以很容易地在浏览器的开发工具中查看。如果我复制 cookie 并通过 JavaScript (document.cookie="JSESSIONID=xyzz") 在不同的浏览器中设置它，然后尝试访问登录后页面，服务器会将其识别为有效请求 session 验证成功。提供登录后页面，无需用户询问用户 ID 和密码。
POC: 用户打开 chrome 并输入 URL http://localhost:8080/mywebapp/ 并使用 admin 和 pass1234。成功登录主页 http://localhost:8080/mywebapp/home 显示。现在 JSESSIONID cookie 被复制并设置在 FireFox 中。用户在 Firefox 中输入 http://localhost:8080/mywebapp/home 并显示主页，无需询问用户 ID 和密码。
问题:如何防止同一 session 在多个浏览器上被复制？
最佳答案
您无法阻止这种简单地从您自己的浏览器复制 cookie 的特定情况(或者通过从 Internet 某处无知者发布的 HTTP 负载复制粘贴/屏幕截图复制 cookie 值)。你最多可以防止cookie被XSS或中间人攻击劫持。
这一切都在关于主题 Session Hijacking 的维基百科页面中进行了详细阐述我删掉了其中不相关的部分(要么已经由 Servlet API 强制执行，要么根本不适用于此处)。
Prevention
Methods to prevent session hijacking include:
- Encryption of the data traffic passed between the parties by using SSL/TLS; in particular the session key (though ideally all traffic for the entire session[11]). This technique is widely relied-upon by web-based banks and other e-commerce services, because it completely prevents sniffing-style attacks. However, it could still be possible to perform some other kind of session hijack. In response, scientists from the Radboud University Nijmegen proposed in 2013 a way to prevent session hijacking by correlating the application session with the SSL/TLS credentials[12]
- (snip, not relevant)
- (snip, not relevant)
- Some services make secondary checks against the identity of the user. For example, a web server could check with each request made that the IP address of the user matched the one last used during that session. This does not prevent attacks by somebody who shares the same IP address, however, and could be frustrating for users whose IP address is liable to change during a browsing session.
- Alternatively, some services will change the value of the cookie with each and every request. This dramatically reduces the window in which an attacker can operate and makes it easy to identify whether an attack has taken place, but can cause other technical problems (for example, two legitimate, closely timed requests from the same client can lead to a token check error on the server).
- (snip, not relevant)
换句话说:
- 使用 HTTPS 而不是 HTTP 来防止中间人攻击。
- 在登录表单中添加“锁定我的 IP”复选框，并拒绝来自与 servlet 过滤器中同一 session 关联的不同 IP 的请求。这仅适用于知道自己拥有固定 IP 的用户。
- 根据每个请求更改 session cookie。乍一看很有趣，但当用户在同一个“ session ”中的多个浏览器选项卡/窗口中打开同一个网站时就会中断。
- 未提及，但请确保您没有 XSS hole任何地方，否则很容易窃取 cookie。
最后但并非最不重要的一点，我想澄清一下，这个问题绝对与 Servlet API 和 JSESSIONID cookie 没有具体关系。所有其他有状态服务器端语言/框架，如 PHP (PHPSESSID) 和 ASP (ASPSESSIONID) 也暴露出完全相同的安全问题。 JSESSIONID 以前(大约十年前)只出现在新闻中，因为默认情况下可以在 URL 中传递 session 标识符(这样做是为了在禁用 cookie 的客户端中支持 HTTP session )。当无知的最终用户复制粘贴带有 JSESSIONID 的完整 URL 以与他人共享链接时，问题就开始了。从 Servlet 3.0 开始，您可以通过强制执行仅 cookie 策略来关闭 URL 中的 JSESSIONID。
<session-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
另见:
关于session - 复制 JSESSIONID cookie 时防止复制 session ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/35579283/