据我所知，这里有两个漏洞：

• 未设置安全标志。初始 HTTP 请求将泄漏会话 cookie，该会话 cookie 可能来自于实例创建的会话，也可能来自于实例http://example.com创建的先前会话https://example.com。相同的泄露会话标识符将被重用 -> 攻击者将有权访问该会话。

• 最初的 HTTP 请求被拦截，并且响应被替换为植入 cookie 的请求，该 cookie 带有攻击者启动的会话的会话标识符。后续请求将重用相同的 cookie。这是会话固定攻击的一种形式。

在这两种情况下，当到达 HTTPS 实例时，服务器无法知道是否使之前的会话无效，因为会话可能是用户启动的合法会话。

我在这里看到的唯一解决方案是在发出请求时使会话无效并重新创建会话https://example.com，然后在会话 cookie 之外使用加密强令牌和后续请求。令牌需要使用一次且仅一次。

如上所述，所有 cookie 都必须标记为安全 ( Owasp )，但如果您希望您的用户仅通过 SSL 访问您的站点，那么您应该启用 HTTP 严格传输安全 (HSTS - Wikipedia )。

第一个将确保不会通过明确的 HTTP 连接发送任何 cookie，后者将确保任何兼容的浏览器在第一次初始访问后始终使用 HTTPS 访问网站（即使用户键入 HTTP，浏览器也会自动将其替换为 HTTPS，而不向服务器发送任何 HTTP 请求）。

除了@GZBK 和@Adnan 的出色答案，我想到的另一件事是应用程序在输出cookie 值时容易受到XSS的攻击。

通常说 cookie 值是未编码输出的，但由于 cookie 通常是通过 HTTPS 设置的，并且不会受到 MITM 的约束，因此用户只能攻击自己，因此不构成危险。但是，如果 HTTP 请求被拦截，并且 cookie 因利用此XSS漏洞而中毒，则在这种情况下，这可能是一个可能的攻击向量。

当然，这不是包含重定向易受攻击的非 HTTPS 请求，因为即使“ example.com”根本没有侦听端口 80，也可以设置此 cookie：攻击者可以 MITM 受害者发出的任何其他 HTTP 请求，将它们重定向到“ http://example.com”攻击者还截获并返回响应以将用户重定向到他们的原始网站，但只有在“ example.com” cookie 已中毒之后。

我可以相信从现在开始我的会话不会受到任何中间人攻击吗？

在不受信任的网络上浏览的唯一真正安全的方法是禁用浏览器中除 HTTPS 之外的所有协议（例如，配置本地代理，但将浏览器设置为对除 HTTPS 之外的所有协议使用无效端口）。HSTS 可以提供帮助，但如果第一个请求被拦截（例如，甚至在您甚至没有考虑访问“ example.com”之前就使用此处描述的技术），您仍然很容易受到攻击。

下面就评论中的新问题进行更新：

[我忘记输入赏金评论] 我是从用户的角度询问的（尽管知道网站/应用程序应该做什么也很有趣）。在什么情况下在浏览器的 URL 栏中输入 example.com 会直接将我定向到https://example.com/？在什么情况下输入http://example.com/会直接将我定向到https://example.com/？如果首先有对http://example.com/的请求，会发生什么不好的事情，作为用户，我如何知道是否发生了不好的事情？– 吉尔斯

如果“”有一个活动的HSTS记录example.com（预加载或用户之前访问过），并且用户在地址栏中键入"example.com"或"http://example.com"在其地址栏中键入，他们将直接进入，"https://example.com"而无需在 HTTP 上发出任何请求。

当 Web 应用程序向用户代理发布 HSTS 策略时，符合标准的用户代理的行为如下： 自动将引用该 Web 应用程序的任何不安全链接转换为安全链接。（比如http://example.com/some/page/在访问服务器之前会被修改为https://example.com/some/page/）如果不能保证连接的安全性（例如服务器的 TLS 证书是自签名的），显示错误消息并且不允许用户访问 Web 应用程序。

如果没有HSTS记录并且用户键入"example.com"或"http://example.com"在他们的地址栏中输入一个不安全的请求，将首先向“ http://example.com”发出一个不安全的请求，该请求通常会以“ Location: https://example.com/”标题进行回复。这将导致浏览器加载 HTTPS URL。如果用户想要确保没有任何东西被注入或更改，并且所发生的Location只是返回了“”标头，他们应该清除所有状态信息。执行此操作的过程应如下所示：

1. 关闭所有其他浏览器窗口和选项卡 - 这将确保没有其他 HTTP 请求被 MITM 处理并重定向到“ example.com”。
2. 在他们的浏览器中禁用 JavaScript。这将确保没有运行在间隔设置 cookie 的脚本。例如，如果通过 cookie 值存在XSS漏洞，则注入的脚本可以通过每隔几秒重置一次来确保 cookie 值保持设置状态。又名僵尸饼干。
3. 清除 cookie、任何本地存储和任何浏览器插件数据（例如本地 Flash/Silverlight）。这将删除该站点的大部分状态信息。
4. 按浏览器上的刷新。这将确保当前页面加载不是 POST，因为用户会收到警告消息。如果存在任何XSS漏洞，则 POST 可能已将内容注入页面。
5. 如果需要，重新启用 JavaScript。

显然，这需要经历很多事情，他们可能更容易使用前面描述的代理技术来禁用 HTTP 并从干净的浏览器开始（例如新的隐身会话）。

如果用户在不受信任的网络上浏览，那么他们永远不会 100% 安全。除非一切都处于已知状态（因此从干净状态/HTTPS 开始或删除所有状态信息），否则无法轻松检查篡改。是的，他们可以手动检查 cookie，但是一旦脚本嵌入页面，攻击者可以通过巧妙的技术清除 cookie。

根据您已使用正确域建立 SSL 连接的前提（并假设您的服务器和浏览器都没有任何漏洞），然后用户通过您的 SSL 证书和他受信任的根证书验证了他加载的页面您的服务器到达时没有被篡改。

我看到以下问题：

1. 如果拦截器可以伪造您的 SSL 证书，那么中间人攻击显然是可能的。因此，如果您已共享它（与您的 CDN？与您的网络托管商的流氓管理员？与法律禁止承认他被传唤获取密钥的同事？），这实际上是一个可能的攻击媒介。如果您首先生成了弱密钥（可能您的系统熵低或使用了损坏的随机数生成器？），也可能发生这种情况。

2. 浏览器配置为信任的任何一个根 CA 都不会受到损害。请注意，它们通常有很多很多，中间人只需要一种妥协就可以为您的域伪造一个明显有效的 SSL 证书。另请注意，某些用户可能会随其供应商（如 Microsoft）按需推送新的根 CA 证书，理论上允许 Microsoft（或任何 CA）的任何（合法？）中间人攻击) 可以说服支持。当然，我们可以希望只有好人才能对公司拥有如此大的权力。

3. 即使看似无关的漏洞也可以明显否定整个论点，即使是那些可能被称为功能而不是错误的漏洞：想象一下中间人最初通过 HTTP 提供网页，导致浏览器切换到全屏显示，并且然后模仿一个典型的浏览器窗口。您假设的超级勤奋用户是否会注意到地址栏及其内容只是他浏览器地址栏的精心模拟...？