Tomcat上的Spring Security/JSF/Hibernate意外会话劫持



前几天发生了一件非常奇怪和尴尬的事情,我无法用语言来描述发生了什么。

我的应用程序在Tomcat7上运行集成了JSF 2.1、Hibernate 4和Spring Security的Spring 3。我和一位来自C级的重要人士通了电话,我们都同时在测试环境中,在同一时间,在相同的页面上。当他的页面显示我的个人账户详细信息时,他去导航到了我正在导航的页面。我不相信他,所以我走到他的办公室,果不其然,他以某种方式登录了我的账户,但他没有密码。

该应用程序将保护患者的健康信息,因此我被要求向C级提供一份完整的报告,说明发生了什么,但我不知道这是怎么可能的。我搜索了代码库,但一无所获。我曾多次尝试重现确切的场景,但都没能重现。我甚至没有一个有根据的猜测,我对此感到满意。

我认为Tomcat应用程序上下文实现中存储的会话上可能存在一些不安全的线程操作,但如果它不可复制,我就无法证明这一点。我还认为,由于Spring Security在其他请求和转发之前是一个Filter,所以可能是其他servlet过滤器之一干扰了它。另外两个是Primefaces文件上传过滤器和我最近添加的Omnifaces SEO过滤器。

事实上,Omnifaces过滤器确实干扰了Primefaces File Upload过滤器,我不得不修改它的配置,这样他们两个才能玩得很好,所以我仍然觉得这可能也是可能的。

Spring Security是否有任何已知的错误导致了类似的问题?Tomcat是否存在从ApplicationContext意外提供错误会话状态的已知问题?其他人有没有经历过类似的问题,或者对此有一些独特的见解?

编辑:发布后不久,我发现了这个,几天前才发布:

会话混淆-apachehttpd与mod_jk、tomcat、spring安全-服务其他用户的数据

它几乎与我在Tomcat前面的Apache httpd+mod_jk插件完全相同,所以我肯定不会疯:)

更新:

我能够在没有mod_jk或Apache的情况下在我的开发环境中重现这个问题,所以我可以可靠地排除这是罪魁祸首。

我想明白了:)

这有点像开发人员的错误,但这也是Spring荒谬的默认行为。我有一个名为SessionBean的JSF托管Bean,我将其声明为@SessionScope。当您集成JSF和Spring时,JSF依赖项注入与Spring依赖项注入冲突,因此Spring重写了处理该问题的JSF模块,只封装Spring DI。因此,当我将JSF ManagedBean声明为Session Scoped时,我还必须给它一个@Controller注释,以便它也被识别为Spring Bean。

然而,Spring并不理解JSF @RequestScoped@SessionScoped注释。Spring有自己的注释,简称为@Scope(value = "request|session|singleton?|etc...")

因为Spring没有识别出我设置的JSF作用域,所以它将新创建的bean作为bean的默认bean处理为SINGLETON。

因此,每次有人登录时,都会重写我用来缓存从身份验证主体获取的登录用户的属性。然后,所有做任何事情的人都以不同的用户身份登录。

顺便说一句,春天很好,警告你你误解了你该死的豆子。

感谢大家的帮助,我希望这对未来的游客有益!

相关内容

  • 没有找到相关文章

最新更新