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会话开始，如果你想在从http切换到https并返回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.

Q1 - 是否可以/希望使用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未找到）。

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屋！