Spring Security / JSF / Hibernate意外会话劫持在Tomcat上？ [英] Spring Security/JSF/Hibernate Accidental Session Hijacking on Tomcat?
问题描述
我的应用程序运行Spring 3与JSF 2.1集成在一起，Hibernate 4，Spring Security都在Tomcat 7上运行。我通过C-level的重要人员接通了电话，我们同时在同一页面上同时处于测试环境。当他的网页提供我的个人帐户详情时，他几乎在同一时刻浏览到我正在导航的页面。我不相信他，所以我走到他的办公室，果然，他以某种方式登录了我的帐户，他没有密码。
应用程序将保护病人的健康信息，因此我被命令为C级人员提供发生了什么事情的完整报告，但我无法找到这是可能的。我搜索了代码库，没有任何结果。我试图在多个场合重现确切的场景，并且从未能够重现它。我甚至没有受过教育的猜测，我对此感到满意。
我想也许可能在存储在Tomcat应用程序上下文实现中的会话中存在一些不安全的线程操作但如果它不可重现，我无法证明这一点。我还认为，由于Spring Security在其他请求之前以Filter的形式运行，并且可能会转发其他servlet过滤器中的其中一个受到干扰。另外两个是我最近添加的Primefaces File Upload过滤器和Omnifaces SEO过滤器。
Omnifaces过滤器事实上干扰了Primefaces File Upload过滤器，不得不修改它的配置，这样他们两个就会相互发挥很好，所以我仍然觉得这可能也是一种可能。
是否有任何已知的错误Spring Security导致了类似的问题？ Tomcat中是否存在关于意外地从ApplicationContext提供错误会话状态的问题？有没有人遇到类似的问题或有一些独特的见解呢？
编辑：发布后不久，我发现这一点，几天前：
会话混合 - apache httpd与mod_jk，tomcat，spring security - 提供其他用户的数据
它的设置几乎与我在Apache Tomcat前面的Apache httpd + mod_jk插件的设置相同，所以我确实不会发疯：）
$ b
更新：
我能够在我的开发环境中重现这个问题，但前面没有mod_jk或Apache，所以我可以可靠地排除这个问题的罪魁祸首。
我发现：）
这是一种开发者错误，但这也是Spring的一个荒谬的默认行为。
我有一个名为SessionBean的JSF Managed 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范围，所以它将它的缺省值作为一个SINGLETON对待新创建的bean。
每次有人登录时，它都会覆盖我用来缓存从认证主体获取的登录用户的属性。然后，每个做任何事情的人都以不同的用户身份登录。
不错，Spring通过警告你，你错误地配置了你该死的bean 。
感谢每个人的帮助，我希望这会给未来的访客带来好处！
Something very strange and embarrassing happened to me the other day and I don't have words to describe what happened.
My app runs Spring 3 integrated with JSF 2.1, Hibernate 4, Spring Security all on Tomcat 7. I was over the phone with someone important from C-level and we were both simultaneously on the test environment at the same time on the same pages. He went to navigate to a page that I was navigating to at pretty much the same moment when his page came up with my personal account details. I didn't believe him, so I walked over to his office and sure enough, he somehow was logged on as my account which he doesn't have the password for.
The application will have protected patient health information so I was ordered to provide C-level a full report with what had happened, but I cannot find how this was possible. I scoured the code base and came up with nothing. I tried to reproduce the exact scenario on multiple occasions and was never able to reproduce it. I don't even have an educated guess that I am happy with.
I think perhaps there might have been some unsafe thread operation on sessions stored in the Tomcat application context implementation but I have no way to prove this if it is not reproducible. I also thought that since Spring Security operates as a Filter ahead of other requests and forwards that perhaps one of the other servlet filters interfered. The other two were the Primefaces File Upload filter and the Omnifaces SEO filter that I had recently added.
The Omnifaces filter did in fact interfere with the Primefaces File Upload filter that I had to tinker with its configuration so the two of them would play nice with each other, so I still feel like that might be a possibility too.
Are there any known bugs with Spring Security that have caused similar issues? Are there known issues with Tomcat regarding accidentally serving the wrong session state from the ApplicationContext? Has anybody else experienced a similar problem or have some unique insight into this?
EDIT: Shortly after posting this I found this, posted only a few days ago:
Session mix up - apache httpd with mod_jk, tomcat, spring security - serving data of other user
It is almost exactly the same setup as I have Apache httpd+mod_jk plugin in front of Tomcat so surely I am not crazy :)
UPDATE:
I was able to reproduce the issue in my development environment without mod_jk or Apache in front, so I can reliably rule this out as the culprit.
I figured it out :)
It was sort of a developer error, but it is also a ridiculous default behavior of Spring.
I had a JSF Managed Bean called SessionBean that I declared as @SessionScope. When you integrate JSF and Spring, the JSF dependency injection conflicts with Spring dependency injection so Spring rewrote the JSF module that handles that to just wrap Spring DI instead. So when I declare a JSF ManagedBean as Session Scoped, I must also give it a @Controller annotation so that it is recognized as a Spring Bean as well.
Turns out that Spring doesn't however understand the JSF @RequestScoped and @SessionScoped annotations. Spring has its own annotation called simply @Scope(value = "request|session|singleton?|etc...") .
Because Spring didn't recognize the JSF scope that I set, it treated the newly created bean in its default for beans, as a SINGLETON.
So everytime somebody logged on, it was overrwriting the property I used to cache the logged in user that I fetched from the Authentication Principal. Then everybody who did anything was logged on as a different user.
Nice of Spring by the way to warn you that you misconfigured your damn bean.
Thanks for everybodies help, I hope this benefits future visitors!
这篇关于Spring Security / JSF / Hibernate意外会话劫持在Tomcat上？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
