Tomcat，从 HTTPS 移动到 HTTP 时保持会话答案

【问题标题】：Tomcat, keep session when moving from HTTPS to HTTPTomcat，从 HTTPS 移动到 HTTP 时保持会话
【发布时间】：2011-06-05 20:17:55
【问题描述】：

我有一个在 Tomcat 6.0.29 上运行的 Java 应用程序，前面是 Apache 2.2.3。登录页面使用 HTTPS，而大多数页面使用 HTTP。

如果用户尝试访问受登录保护的页面 (HTTP)，他会被重定向到登录页面 (HTTPS)、登录，然后被重定向回最初请求的页面。这很好用，因为 JSESSIONID cookie 被设置为不安全的，并且用于 HTTP 和 HTTPS。

但是，如果用户从登录页面 (HTTPS) 开始，则 JSESSIONID cookie 设置为 Secure，因此在登录后重定向到 HTTP 下的页面时会话不可用，从而强制新会话并重定向到登录页面再次。不过这次它起作用了，因为这一次 JSESSIONID cookie 被设置为不安全的。

如何避免用户第一次点击登录页面时必须登录两次？

【问题讨论】：

HTTPS login not saving the JSESSIONID in a cookie 的可能重复项
谢谢@leonbloy。这是非常相关的（除了我自己控制登录页面）。在过滤器中添加非安全 cookie 的解决方案可以做到。但这感觉就像一个黑客，必须有更好的方法..
最简单的解决方案可能是 98% 的网站，让登录页面不安全，同时发布到安全的 URL。但这是一个安全问题，因为中间人可能会更改帖子 URL 并收集用户名/密码
你可以做一些明智的事情，让整个网站都需要在 https 后面进行身份验证。如果您要发送身份验证 cookie 并且可能是不安全的受限数据，那么开始使用受保护的登录表单是没有意义的。
@OrangeDog 我知道，但这对这个特定的应用程序来说并不是很大的威胁。关于运行纯 HTTPS 的优缺点，SO 上有一些线程。我读过它们，我的结论是我不想读。像大多数网站一样，例如stackoverflow.com

【解决方案1】：

（更新：为清楚起见）从登录 Http get/post 开始使用 https 并在用户登录会话中使用 https。

只有在没有登录用户时才使用 Http。

cookie 不允许跨越协议边界是有原因的——它是一种攻击媒介！（* 请参阅下面的更新）

如何做这个非常糟糕的主意

如果您真的坚持，请将重定向中的 jsessionId 编码到 http url（或始终在 url 中编码 jsession id）。当 Tomcat 获得 http 重定向时，tomcat 应该找到会话并继续。

为什么你不应该这样做

说真的，任何在同一页面上混合 https 和 http 内容的网站都会让自己面临各种有趣（和简单）的攻击。

如果会话的其余部分是明文，那么从 https 开始保持登录“安全”是没有意义的。那么用户名/密码（可能只是密码）受到什么保护？

使用流行的中间人攻击，攻击者只需复制会话 ID 并使用它来获得乐趣。由于大多数网站不会使保持活动状态的会话过期，因此 MIM 实际上拥有完全访问权限，就像他们拥有密码一样。

如果您认为 https 在性能方面很昂贵，请查看 here，或者只是搜索。将 https 性能提高到可接受的最简单方法是确保服务器在连接上设置保持活动状态。

【讨论】：

所以你的意思是每个有某种登录形式的网站都应该对所有页面使用 HTTPS，而使用 HTTP 的网站不应该使用会话。
没有。我的意思是，一旦用户登录到某个站点，进出该站点的所有流量应该通过 https 进行，直到用户注销为止。我刚刚编辑了原始答案。
Twitter、facebook、stackoverflow 等似乎不同意
Google 和银行都同意。嘿，但继续做它并使用 sessionId 对 url 进行编码。如果您的服务没有风险“那么”大的资产，无论如何。只要意识到会话劫持是确定无疑的。这就是羊墙 (wallofsheep.com) 存在的原因。
谢谢@Pat，我知道风险。即使您已登录，Google 搜索也会使用 HTTP。但我怀疑您指的是 Gmail 和日历等 Google 产品。他们以及银行都显示高度敏感的数据。银行甚至使用由计算器提供或通过 SMS 发送的令牌来保护登录。每个应用程序都需要选择其安全级别。我的应用程序是只读的，并且显示的数据也可以公开，但目前仅限于一群人。如果有人劫持了会话，他们将能够看到火车在哪里以及它们有多晚。没有伤害。