HSTS 与仅带有安全 cookie 的 https答案

【问题标题】：HSTS vs only https with secure cookieHSTS 与仅带有安全 cookie 的 https
【发布时间】：2013-03-07 13:02:27
【问题描述】：

如果我的网站使用安全会话 cookie 在 https 上提供服务并将任何对 http url 的尝试重定向到 https，它是否足以提供保护？

如果不设置 HSTS 标头，我会在此设置中暴露哪些安全漏洞？

【问题讨论】：

【解决方案1】：

此策略通过使攻击者难以欺骗您的用户使用 SSL 以外的其他方式访问您的网站，从而防止被动窃听。它还可能确保用户存储的任何书签都指向 https URL，这很好。但是，HSTS 在发生中间人攻击时仍然具有优势。

HSTS 试图解决的问题的核心是浏览器不知道给定站点是否应该使用 SSL。而且大多数用户不会先明确尝试 SSL；如果他们输入 URL，他们通常会首先访问非 SSL http 站点，而且通常他们只是跟随链接。如果攻击者可以诱骗您的用户通过 http URL 访问您的站点，并且可以坐在用户流量的中间（例如，通过成为他们的无线 AP），那么该攻击者可以发起中间人攻击通过将用户的流量代理到您的站点并在没有 SSL 的情况下将站点呈现给用户来针对您的站点（这是一种降级攻击）。由于用户不会看到 SSL，因此他们的浏览器不会识别出攻击者没有您网站的有效证书，并且他们没有直接连接到您的网站。（更复杂的方法是拦截 SSL 流量并为您的站点提供自签名或其他无效证书，但这通常会导致浏览器警告。）

在这种情况下，将非 SSL 用户重定向到 SSL 或在 cookie 上设置安全标志实际上对您没有多大帮助。中间人攻击者将连接到您的 SSL 站点（并将用户的操作代理到该站点），并在将 cookie 传递给用户时将其删除。

当然，攻击者也可以删除 HSTS 标头。然而，HSTS 协议的要点是，如果用户过去曾成功直接访问您的站点，他们的浏览器会记住您的站点发送了 HSTS。如果他们稍后连接到您的站点并发现它没有使用 SSL 或浏览器无法验证证书，浏览器将抛出错误并拒绝继续。如果浏览器支持 HSTS 并将您的网站记录为需要 SSL，这将防止攻击者将您的网站降级为非 SSL。

维基百科有一个fairly good discussion of this，我认为这比the RFC 中的讨论要清晰一些。

【讨论】：

我认为您在句子中犯了一个错误“中间人攻击者将连接到您的 SSL 站点（并将用户的操作代理到该站点），并且只会删除安全将它们传递给用户时从您的 cookie 中标记”。 MITM 攻击者（例如通过 ARP 欺骗）无法删除安全标志，因为如果有安全标志，如果请求未使用 HTTPS，则不会发送 cookie。对于其余的我同意你的看法，HSTS 添加了额外的保护，以防止攻击者读取或编辑用户将看到的 HTTP 请求/响应和 HTML 代码。
@baptx，据我了解，MITM 会在向用户发送第一个响应之前删除安全标志。因此，操作 Set-Cookie 响应标头。因此，它会在没有安全标志的情况下被浏览器接收，然后通过普通 http 发送回。