背景:我在tomcat上部署了一个Javaee Web应用程序,它使用基于表单的身份验证。Web服务器收到登录请求后,会将请求发送到专用的身份验证服务,该服务验证用户登录(用户ID和密码)。身份验证成功后,用户会话将保留在Web服务器中。
问题:我在这里编写了一个简单的webpp源代码来模拟这种情况。成功登录后,当前HttpSession
实例无效,并创建新实例。对于每个登录后登录页面的请求,都会验证会话。设置了一个新的JSESSIONID
cookie,用于在会话期间标识用户,直到会话过期或用户注销为止。可以在浏览器的开发工具中轻松查看此cookie。如果我复制cookie并通过JavaScript(document.cookie="JSESSIONID=xyzz"
)在其他浏览器中进行设置,然后尝试访问登录后页面,则服务器会将其标识为有效请求,并且会话已成功验证。无需用户输入用户ID和密码即可向帖子登录页面提供服务。
POC:用户打开浏览器和输入网址http://localhost:8080/mywebapp/
与和日志admin
和pass1234
。成功登录后,将显示主页http://localhost:8080/mywebapp/home
。现在,将JSESSIONID
cookie复制并在FireFox中设置。用户输入http://localhost:8080/mywebapp/home
Firefox并显示在主页上,而无需输入userId和password。
问题:如何防止通过多个浏览器复制同一会话的情况?
您不能阻止仅从您自己的浏览器复制cookie(或通过从Internet上某个无知者发布的HTTP有效负载复制粘贴/截图复制cookie值)来阻止这种特殊情况的情况。您最多可以防止Cookie被XSS或中间人攻击劫持。
This all is elaborated in Wikipedia page on the subject Session Hijacking of which I snipped away irrelevant parts (either already enforced by Servlet API, or are simply not applicable here).
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)
In other words:
Last but not least, I'd like to make clear that this problem is absolutely not specifically related to Servlet API and the JSESSIONID cookie. All other stateful server side languages/frameworks such as PHP (PHPSESSID) and ASP (ASPSESSIONID) also expose exactly the same security problem. The JSESSIONID was previously (decade ago orso) only a bit more in news because by default it was possible to pass the session identifier along in the URL (which was done to support HTTP session in clients who have cookies disabled). Trouble started when ignorant endusers copypasted the full URL with JSESSIONID inside to share links with others. Since Servlet 3.0 you can turn off JSESSIONID in URLs by enforcing a cookie-only policy.
<session-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句