【发布时间】: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