Tomcat会话管理——url重写和从http切换到https [英] Tomcat session management - url rewrite and switching from http to https

问题描述

我是 C 的老手，但我是 Java/Tomcat 的新手.

I'm an old hand at C but a raw newbie at Java/Tomcat.

我对单独在 http 中的 Tomcat 会话管理没问题.当我开始考虑切换到 https 时，我遇到了问题.

I'm fine with Tomcat session management in http alone. Its when I've come to look at switching to https that I've had problems.

我为 Tomcat 收集到，如果您想在从 http 切换到 https 再切换回 http 时保持会话，则必须从 http 会话开始.当浏览器启用 cookie 时，这对我来说很好用.

I gather for Tomcat that you have to start with an http session if you want to maintain a session as you switch from http to https and back to http. This works fine for me when the browser is enabled for cookies.

但是当浏览器禁用 cookie 时(并且正在使用 URL 重写)，然后将 http 切换到 https 或再次返回会导致每次都启动新的会话.我假设这是一个安全问题.

But when the browser is disabled for cookies (and URL rewriting is being used) then switching http to https or back again causes a fresh session to be started each time. I'm assuming this is a security thing.

问题 1 - 是否可以/需要使用 URL 重写来维持 http 和 https 之间的会话?

Q1 - Is it possible/desirable to maintain a session between http and https using URL rewriting?

Q2 - 如果不可能，那么电子商务开发者会如何处理非 cookie 用户?

Q2 - If it isnt possible then what do e-commerce developers do about non-cookie users?

我不想阻止非 cookie 用户使用我的网站.我确实想要在 http 和 https 之间灵活切换.

I dont want to prevent non-cookie people using my site. I do want some flexibility switching between http and https.

感谢您的帮助，史蒂文.

thanks for any help, Steven.

推荐答案

使用相同的 cookie 或 URL 令牌来维护 HTTP 和 HTTPS 之间的会话似乎并不可取.

It doesn't seem desirable to maintain session between HTTP and HTTPS using the same cookie or URL token.

想象一下您是用户登录的情况，对于电子商务网站中的每个请求/响应来回传递给定的 cookie(或 URL 令牌).如果中间人能够读取该 cookie，他就可以使用它登录到该站点的 HTTP 或 HTTPS 变体.即使合法用户所做的一切都是通过 HTTPS 进行的，攻击者仍然可以访问该会话(因为他也将拥有合法的 cookie).他可以看到购物车、付款方式等页面，也许还会更改送货地址.

Imagine the case where you're user is logged on, with a given cookie (or URL token) passed back and forth for every request/response in an e-commerce website. If someone in the middle is able to read that cookie, he can then log on to the HTTP or HTTPS variant of the site with it. Even if whatever the legitimate user is then doing is over HTTPS, the attacker will still be able to access that session (because he too will have the legitimate cookie). He could see pages like the cart, the payment method, perhaps change the delivery address.

在 HTTP 会话和 HTTPS 会话(如果您使用会话)之间传递某种形式的令牌是有意义的，但将它们视为一个并且相同会导致一些漏洞.在查询参数中创建一次性令牌只是转换可能是一种解决方案.但是，您应该将它们视为两个单独的经过身份验证的会话.

It makes sense to pass some form of token between the HTTP session and the HTTPS session (if you're using sessions), but treating them as one and the same would cause some vulnerability. Creating a one-off token in the query parameter just the transition could be a solution. You should however treat them as two separate authenticated sessions.

此漏洞有时会发生在使用混合 HTTP 和 HTTPS 内容的网站上(某些浏览器，例如 Firefox 会在发生这种情况时向您发出警告，尽管大多数人倾向于在它第一次弹出时将其禁用).您可以将 HTTPS 会话 cookie 用于主页，但该页面包含公司徽标的图像，通过纯 HTTP.不幸的是，浏览器会为两者发送 cookie(这样攻击者就可以获取 cookie).我已经看到它发生了，即使有问题的图像甚至不存在(浏览器会将带有 cookie 的请求发送到服务器，即使它返回 404 not found).

This vulnerability can happen sometimes with websites that use mixed HTTP and HTTPS content (certain browsers such as Firefox will give you a warning when that happens, although most people tend to disable it the first time it pops up). You could have your HTTPS session cookie for the main page, but that page contains images for the company logo, over plain HTTP. Unfortunately, the browser would send the cookie for both (so the attacker would be able the cookie then). I've seen it happen, even if the image in question wasn't even there (the browser would send the request with the cookie to the server, even if it returned a 404 not found).

这篇关于Tomcat会话管理——url重写和从http切换到https的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！