我有一个在Tomcat 6.0.29上运行的
Java应用程序,Apache 2.2.3在前面.
登录页面使用HTTPS,而大多数页面使用HTTP.
登录页面使用HTTPS,而大多数页面使用HTTP.
如果用户尝试访问受登录保护的页面(HTTP),则将其重定向到登录页面(HTTPS),登录,然后被重定向到原始请求的页面.
这是非常好的,因为JSESSIONID cookie设置为不安全,并且用于HTTP和HTTPS.
但是,如果用户在登录页面(HTTPS)中启动,则将JSESSIONID cookie设置为“安全”,因此在重定向到HTTP页面之后登录时,会话不可用,从而强制重新启动会话并重定向到登录页面.这一次它可以工作,因为这次JSESSIONID cookie设置为不安全.
解决方法
(更新：为了清楚)从登录开始Http获取/发布使用https并使用https通过用户的登录会话.
有一个原因是cookie不允许跨协议边界 – 这是一个攻击矢量！ (*参见下面的更新)
怎么做这个很不好的主意
如果你真的坚持,将重定向中的jsessionId编码到http url(或者总是在url中编码jsession id).当Tomcat获取http重定向时,tomcat应该查找会话并继续.
为什么你不应该这样做
严重的是,任何在同一页面上混合https和http内容的网站只是开启各种有趣(和容易的)攻击.
如果会话的其余部分是明文,从https保持登录“安全”是无意义的.那么用户名/密码(可能只是密码)是受到保护的呢？
使用受欢迎的中间人攻击,攻击者只是复制会话ID并使用它来获得乐趣.由于大多数网站不会使保持活动的会话过期,因此MIM具有完全访问权限,就像他们拥有密码一样.
如果你认为https在性能方面比较昂贵here,或者只是搜索.提高https性能可接受的最简单的方法是确保服务器在连接上设置保持活动状态.
>更新1：
更多见Session Hijacking或Http Cookie Theft
>更新2：
请参阅Firesheep Firefox plugin如何快速,轻松地做到这一点.