在同一域但不同端口上通过 HTTP 提供页面作为通过 HTTPS 提供的服务是否存在任何安全隐患？

Question

如果我有一个 HTML 页面在 http://example.com:123 上通过 HTTP 提供服务，另一个通过 HTTPS 在https://example.com:456/some_app 提供服务，那么 HTTPS 应用程序是否存在风险？请注意，假设已采取以下缓解措施：

• HTTP 页面完全未经身份验证并包含公共信息
• HTTPS 页面的 cookie 标记为 secure
• HTTPS 页面使用双重提交等标准反 CSRF 模式

我看到的主要风险是攻击者可以拦截 HTTP 请求并发送回带有恶意 Javascript 的页面。虽然这是不可取的，但我看不到攻击可能升级的任何方式。尽管对 cookie 的访问控制过于宽松，但攻击者应该无法窃取 HTTPS 页面的 cookie，因为它们被标记为安全的。就跨源请求而言，HTTP 页面发出的请求被视为来自不同的源，因此 CSRF 保护在那里起作用。

有没有我遗漏的攻击地点？还是 HTTPS 应用程序相当安全？

Answer 1

cookie 的“安全”属性可防止通过 http 请求发送 cookie，因此它们仅通过 https 发送。但是，没有什么可以阻止 http 页面上的 javascript读取 cookie，例如，如果它在传输过程中被篡改以包含额外的 javascript，或者容易受到 XSS 漏洞的攻击。

这可以通过设置 HttpOnly 标志和安全标志来解决，但如果需要 JavaScript 来读取 cookie，这可能不适用于您的双重保护 CSRF 实施。

编辑：下面的评论指出 Chrome （至少）在设置安全标志时会阻止这种情况，但我看不到在 RFC 中明确指出这一点，实际上第 8.5 节指出 cookie 并不总是遵循相同的限制通过 document.cookie 访问时的方案和路径。它还给出了使用 document.cookie 在本地访问时忽略路径限制的示例——尽管诚然没有明确提及是否可以从非 https 页面上的 javascript 读取安全 cookie。我会在谨慎方面犯错，因此假设它们对 http 页面上的 javascript 不安全，除非设置了 HttpOnly 标志。

另一个问题是没有什么可以阻止 Http 页面设置 cookie，并覆盖现有的。同样，这可以通过拦截 http 页面响应并添加 Set-Cookie 标头来实现，或者通过在易受 XSS 攻击的页面上使用 javascript 来实现。虽然您可能认为覆盖 cookie 不会导致太多问题，但它可能会以其他人的身份登录，例如，此人可能没有意识到他们可能会在此错误登录下输入其他私人数据。

当然，您的 https 页面也可能容易受到 XSS 的攻击，但提到的拦截攻击只是不安全 http 的问题（顺便说一句，我在其中包括配置不当的 https）。此外，用户和开发人员通常会不太小心地处理 http 页面，并且还会毫无错误地加载不安全的第三方内容。因此可能更容易受到 XSS 或其他问题的影响。

更不用说只有端口号不同的事实，您的 http 站点可能会被拦截，并将您的 https 站点看起来像一个钓鱼站点，希望您的访问者对服务器名称感到满意并且不要'不要注意到错误的端口。

这些只是我能想到的几个问题。

我强烈建议不要在同一服务器名称上允许 http 和 https，建议到处使用 https，甚至建议使用 HSTS 来确保这一点。