are*_*res 4 cookies session tomcat servlets java-ee
背景:我在tomcat上部署了一个使用基于表单的身份验证的javaee webapp.当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和密码的质询.
问题:如何通过多个浏览器复制相同的会话,如何防止这种情况?
您无法阻止这种仅从您自己的浏览器中复制cookie的特定情况(或通过从互联网上某处无知的HTTP有效负载copypaste /屏幕截图中复制cookie值).您最多可以防止cookie被XSS或中间人攻击劫持.
这一切都在Wikipedia页面上详细阐述了主题Session Hijacking,其中我删除了不相关的部分(已经由Servlet API强制执行,或者根本不适用于此处).
预防
防止会话劫持的方法包括:
- 使用SSL/TLS 加密双方之间传递的数据流量; 尤其是会话密钥(尽管理想情况下是整个会话的所有流量[11]).基于网络的银行和其他电子商务服务广泛依赖这种技术,因为它完全可以防止嗅探式攻击.但是,仍然可以执行其他类型的会话劫持.作为回应,来自Radboud University Nijmegen的科学家在2013年提出了一种通过将应用程序会话与SSL/TLS凭证相关联来防止会话劫持的方法[12]
- (剪辑,不相关)
- (剪辑,不相关)
- 某些服务会根据用户的身份进行二次检查.例如,Web服务器可以检查每个请求,即用户的IP地址与该会话期间最后使用的IP地址匹配.但是,这并不能阻止共享相同IP地址的人的攻击,并且对于IP地址在浏览会话期间可能发生变化的用户而言可能会令人沮丧.
- 或者,某些服务会根据每个请求更改cookie的值.这大大减少了攻击者可以操作的窗口,并且可以轻松识别是否发生了攻击,但是可能导致其他技术问题(例如,来自同一客户端的两个合法,紧密定时的请求可能导致令牌检查服务器上的错误).
- (剪辑,不相关)
换一种说法:
最后但同样重要的是,我想明确指出,这个问题绝对与Servlet API和JSESSIONID cookie没有特别的关系.所有其他有状态服务器端语言/框架(如PHP(PHPSESSID)和ASP(ASPSESSIONID))也会暴露出完全相同的安全问题.JSESSIONID以前(十年前orso)在新闻中只有一点点,因为默认情况下可以在URL中传递会话标识符(这是为了支持禁用cookie的客户端中的HTTP会话).当无知的最终用户使用里面的JSESSIONID复制完整的URL以与他人共享链接时,麻烦就开始了.从Servlet 3.0开始,您可以通过强制执行仅限cookie的策略来关闭URL中的JSESSIONID.
<session-config>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
Run Code Online (Sandbox Code Playgroud)
归档时间: |
|
查看次数: |
5143 次 |
最近记录: |