使用相同的 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).