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

【问题标题】：Spring Security/JSF/Hibernate Accidental Session Hijacking on Tomcat?Tomcat 上的 Spring Security/JSF/Hibernate 意外会话劫持？
【发布时间】：2013-01-28 12:33:42
【问题描述】：

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

我的应用程序在 Tomcat 7 上运行与 JSF 2.1、Hibernate 4、Spring Security 集成的 Spring 3。我正在与 C 级的重要人物通电话，我们同时在测试环境中相同的页面。当他的页面出现我的个人帐户详细信息时，他几乎在同一时刻导航到了我正在导航的页面。我不相信他，所以我走到他的办公室，果然，他不知何故以我的帐户登录，而他没有密码。

该应用程序将保护患者的健康信息，因此我被要求向 C 级人员提供一份完整报告，说明所发生的事情，但我不知道这怎么可能。我搜索了代码库，一无所获。我试图在多个场合重现确切的场景，但始终无法重现。我什至没有一个令我满意的有根据的猜测。

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

事实上，Omnifaces 过滤器确实干扰了 Primefaces 文件上传过滤器，我不得不修改它的配置，以便它们两个可以很好地相互配合，所以我仍然觉得这也是一种可能性。

Spring Security 中是否存在任何已知的导致类似问题的错误？ Tomcat 是否存在关于从 ApplicationContext 意外提供错误会话状态的已知问题？有没有其他人遇到过类似的问题或对此有独特的见解？

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

Session mix up - apache httpd with mod_jk, tomcat, spring security - serving data of other user

这与我在 Tomcat 前面安装 Apache httpd+mod_jk 插件的设置几乎完全相同，所以我肯定不是疯了 :)

更新：

我能够在没有 mod_jk 或 Apache 的情况下在我的开发环境中重现该问题，因此我可以可靠地将其排除为罪魁祸首。

【问题讨论】：

当人们在 SO 上看到其他人的帐户时，这归结为 ISP 过度激进的缓存。那么您和应用程序之间是否存在代理/缓存？
@ChrisF Just Apache 委托给 mod_jk Tomcat 连接器。它是一个同时运行 Apache 和 Tomcat 的单一服务器。也许 Apache 正在缓存一些东西？我将尝试删除它，看看是否可以重现错误。

标签： hibernate tomcat spring-security omnifaces session-hijacking

【解决方案1】：

我想通了:)

这是一个开发人员错误，但它也是 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 的默认值，即 SINGLETON。

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

顺便说一句，Spring 的好处是警告你你错误地配置了你该死的 bean。

感谢大家的帮助，希望对以后的访问者有所帮助！

【讨论】：