http 到 https 重定向的安全性

Question

我有一个 100% 使用 https 的网站，并且只能作为 https 使用。我的网站是一个在 IIS 7.5 上运行的 asp.net mvc 应用程序。

它位于多个服务器上，流量通过负载平衡器分配。

我无法控制硬件。

对于 http 请求，我希望它可以在负载均衡器处停止并在此时重定向到 https。

但是硬件公司不会为我做这件事，而是我需要在服务器上的 IIS 中进行从 http 到 https 的重定向。因此，未加密的流量可以通过重定向在服务器级别进入内部网络。在负载均衡器上进行这样的传输会让我感觉更舒服。

我有正当的顾虑吗？

Answer 1

威胁模型：

HTTP request:

           Attacker
              |         Security Boundary
              V         V
Client -- http request --> Load Balancer 
                               |
Client <-- redirect -----------+

无论采用何种方法都允许 HTTP 重定向而产生的威胁：

• 欺骗：客户端可以连接到 MITM 欺骗的 HTTP 服务器，该服务器不通过重定向，而是代理连接到实际的 HTTPS 服务器
• 篡改：客户端可以从 MITM 欺骗服务器接收重定向 URL，将它们定向到另一个操作（例如：客户端接收重定向到 https://yoursite.com/login.aspx?redirect=/deleteAllDocuments）
• 信息泄露：初始 HTTP 请求被泄露，POST 或 GET 中的任何信息都可以在未加密的情况下提供给窃听者。

在目标服务器以外的服务器上执行重定向的参数：

• 防火墙可以限制为 HTTPS 数据，从而限制由于配置错误而导致数据未加密的风险
• 至少从政治角度来看，配置和责任可能成为“别人的问题”
• HTTP 服务器中的漏洞将被隔离，不能用于攻击 HTTPS 服务器或底层应用程序

在负载均衡器以外的东西上执行重定向的参数：

• 负载平衡器不是服务器
• 负载平衡器不是服务器，因此在用作服务器时可能会使用少量代码路径，这可能更容易出现未发现的错误或性能问题
• 您无法使用配置，但您（或您的公司）仍可能对发生的任何错误配置负责（从法律角度）

根据上述分析，为了获得最高的安全性和最低的风险：

• 我不会将重定向放在目标服务器或负载平衡器上，而是放在仅用于重定向页面的 VM 上。一个最小的 Linux 或 Windows 机器应该能够被紧紧锁定以限制暴露。
• 我不允许使用查询字符串或 POST 数据进行重定向（例如：对任何非 GET / HTTP/1.1 请求显示 404）
• 我将欺骗和篡改的可能性称为可接受的风险，或者向用户显示一个页面，说明必须使用 HTTPS 而不是使用重定向来访问该站点

但是，如果您可以假设满足以下条件，则将 HTTP 服务器与 HTTPS 服务器共存不应降低安全性。

• HTTPS 服务器中存在 HTTP 服务器中的任何错误
• HTTP 服务器已正确配置为禁止访问受保护的资源（例如，在 IIS 中设置为单独的站点。安全站点仍然没有 HTTP 绑定）
• 没有其他应用程序能够在 HTTP 上创建服务器（例如，netsh urlacl 只有 IIS）
• 对配置进行审计以确保正确维护上述配置（定期渗透测试、手动配置审查、配置更改管理以及 IDS 或 IPS 系统）

在某些情况下，降低的复杂性甚至可能比单独的服务器更容易保护。此外，如果管理员不熟悉负载均衡器的配置，他们可能更容易在配置中犯严重错误，而不是在他们熟悉的产品中进行相同的配置。

Answer 2

我有正当的顾虑吗？

您对通过 HTTP 进行的初始连接有充分的担忧吗？当然。在中间人攻击中，可以拦截初始请求并欺骗响应。然后，攻击者可以阻止用户使用 HTTP（在攻击者和您的服务器之间添加 ssl/tls 并以明文方式转发给受害者），或者可以与客户端创建一个冒名顶替的 SSL 会话，该会话在被重新攻击之前终止于攻击者。在发送给您的途中加密（使用各种欺骗技术使攻击对普通用户不那么明显）。

但是，如果发起了这样的攻击，我会远更担心从客户端到负载平衡器的传输，而不是负载平衡器和 IIS 之间的传输。如果您怀疑负载均衡器背后有恶意系统，那么您将遇到一系列完全不同的问题。

Answer 3

有关从 HTTP 重定向到 HTTPS 的一些相关信息，请参阅 security.so 上的 my answer。