【问题标题】:Why do browsers accept secure cookies sent over a non-secure (HTTP) connection?为什么浏览器接受通过非安全 (HTTP) 连接发送的安全 cookie?
【发布时间】:2014-03-07 03:16:02
【问题描述】:

当 IE 11、Firefox 26、Chrome 32 等浏览器通过指定了“安全”属性的不安全 (HTTP) 连接接收 Cookie 时,它​​们会存储 cookie 并在向通过安全 (HTTPS) 连接使用同一台服务器。

虽然这可能符合某些规范(我猜是 Netscape Cookies),但我想知道这是否会给受 SSL 保护的网站带来额外的安全漏洞(会话固定)。

考虑以下场景:

用户(拥有干净/无恶意软件的客户端设备)想要通过非安全网络(例如未加密的 WiFi 热点)访问具有用户名+密码登录的网站,攻击者可以在其中读取和修改所有数据通过该网络发送。让网站的 DNS 名称为www.example.com

用户知道,当本网站要求他输入密码时,在输入密码之前总是查看浏览器的地址栏是否包含 SSL 锁图标。

网站:

  • 通过 SSL/TLS 提供对其所有页面和资源的访问。这意味着一旦用户使用 https 访问页面,该页面上的每个内部链接都是 https 链接,因此它们不会“降级”从 HTTPS 到 HTTP 的连接。此外,它不包含任何混合 (HTTP/HTTPS) 内容。
  • 如果用户通过 HTTP 访问其页面之一,则使用 301 状态代码将用户从 HTTP 重定向到 HTTPS。
  • 将登录信息存储在会话 Cookie 中。
  • 确保发送到客户端的所有 Cookie(包括会话 cookie)仅通过安全 (HTTPS) 连接发送,并且始终设置“安全”和“HttpOnly”属性。
  • 仅接受网站生成的会话标识符,并通过设置了“安全”属性的 Cookie 从客户端发送(网站不接受来自 URL 等的会话标识符)
  • 通过在 HTML 表单上设置用户特定的令牌来保护 CSRF,当用户提交 POST 请求时服务器会检查该令牌。
  • 通过正确编码输出为 HTML 的所有字符串来防止 XSS。
  • 没有实现 HSTS,或者用户的浏览器不支持 HSTS(如 IE、Safari)。
  • 不会在用户登录时更改会话标识符(会话 Cookie 的值)。

现在,假设攻击者运行一个程序来拦截通过非安全 HTTP 请求发送的所有数据,如果这些是 HTML 页面,则插入一个片段,使浏览器向 www.example.com 发送 HTTP 请求,例如一个不可见的 img 或 iframe 标签:

<img src="http://www.example.com/" style="display: none;" />

攻击者随后自行访问https://www.example.com/,获取服务器生成的会话cookie,并继续浏览该站点以保持会话活动。 然后,他还将来自用户的 HTTP 请求修改为 www.example.com,以在攻击者刚刚从服务器获得的 HTTP 响应中包含相同的会话 cookie。 cookie 设置了“安全”标志。

现在,假设用户访问一些不传输敏感数据因此没有 SSL 的常规 HTTP 站点。这意味着用户的浏览器将收到攻击者针对这些请求发送的会话 cookie。

稍后,用户转到https://www.example.com/ 并想要登录。他查看地址栏以确保显示 SSL 图标,并使用他的密码登录。但是,由于攻击者之前通过在不安全的 HTTP 请求上发送具有“安全”属性的 cookie 来固定用户的会话,因此攻击者现在可以访问用户的会话状态。

请注意,如果网站在用户登录时更改了会话标识符,则攻击者将无法访问用户的会话状态,但攻击者仍然可以以自己的身份登录并发送他的会话cookie 给用户,覆盖之前的会话/登录 cookie,以便用户代表攻击者执行操作(例如写敏感邮件等)。

我对这个浏览器行为的印象是它引入了一个额外的会话固定场景,如上所述。我可以看到防止这种情况的唯一方法是更改​​每个请求的会话标识符(对于 HTML 页面)。

我错过了什么吗?

我的观点是,如果浏览器拒绝设置了“安全”属性但通过不安全的 HTTP 连接发送的 cookie,攻击者将无法:

  • 在设置了“安全”属性的用户浏览器中注入会话 cookie,因为浏览器会拒绝它,并且
  • (编辑:不适用)在没有设置“安全”属性的用户浏览器中注入会话 cookie,因为网站会忽略没有“安全”属性的 cookie。

这将使特定网站无需随每个请求更改会话标识符。

编辑:好的,我错过的一件事是浏览器似乎没有将 Cookie 标头上的“安全”属性发送回服务器,因此服务器无法确定是否此 cookie 被设置为具有“安全”属性的客户端浏览器。

但这意味着,即使浏览器在非 SSL 连接上拒绝带有“安全”标志的 cookie,攻击者也有可能设置一个没有“安全”标志的 cookie,然后网站会接受该 cookie在 HTTPS 请求上,因为它无法检查 cookie 的“安全”标志。

有什么想法吗?

谢谢!

【问题讨论】:

  • 是的,RFC 6265 确切地说:“虽然看起来对保护 cookie 免受活跃的网络攻击者有用,但 Secure 属性仅保护 cookie 的机密性。活跃的网络攻击者可以覆盖来自不安全通道的安全 cookie,从而破坏它们的完整性”,
  • ... 和later on“一个活跃的网络攻击者还可以通过模拟来自http://example.com/ 的响应并注入一个Set-Cookie 标头,将cookie 注入发送到https://example.com/ 的Cookie 标头中. example.com 上的 HTTPS 服务器将无法将这些 cookie 与其在 HTTPS 响应中设置的 cookie 区分开来。”
  • 服务器通过不安全的通道发送本应安全的cookie时发生安全故障。
  • 嗨@Gumbo:攻击者的服务器故意通过不安全的通道发送安全cookie - 网站本身仅通过安全通道发送安全cookie。但是,后来我意识到攻击者不需要在 cookie 上设置“安全”标志来进行这次攻击。
  • 嗨@CBroe:谢谢,我不知道RFC 6265中已经提到了这一点。所以我唯一的选择是:1)实现HSTS并希望所有浏览器尽快支持,和 2) 作为一种解决方法,在登录时更改会话 ID? (在我写的每个请求都更改它的问题中,但后来我意识到它并没有比在登录时更改会话 ID 更有帮助)

标签: security session cookies ssl


【解决方案1】:

你是对的,这是安全标志的已知限制。来自https://www.rfc-editor.org/rfc/rfc6265#section-4.1.2.5

Although seemingly useful for protecting cookies from active network
attackers, the Secure attribute protects only the cookie's
confidentiality.  An active network attacker can overwrite Secure
cookies from an insecure channel, disrupting their integrity (see
Section 8.6 for more details).

然后来自https://www.rfc-editor.org/rfc/rfc6265#section-8.6

8.6.  Weak Integrity

Cookies do not provide integrity guarantees for sibling domains (and
their subdomains).  For example, consider foo.example.com and
bar.example.com.  The foo.example.com server can set a cookie with a
Domain attribute of "example.com" (possibly overwriting an existing
"example.com" cookie set by bar.example.com), and the user agent will
include that cookie in HTTP requests to bar.example.com.  In the
worst case, bar.example.com will be unable to distinguish this cookie
from a cookie it set itself.  The foo.example.com server might be
able to leverage this ability to mount an attack against
bar.example.com.

我认为您最好的选择是不要过度依赖 cookie 来满足与安全相关的要求:b

【讨论】:

  • 等一下,我看到@CBroe 已经在您的问题的 cmets 中提到了这一点。好吧,无论如何,我会把这个留在这里给其他对未来感兴趣的人,我认为答案更容易找到/阅读。
  • 那你会依赖什么?
猜你喜欢
  • 2015-12-02
  • 2012-10-06
  • 2015-12-07
  • 2020-06-14
  • 2013-05-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多