Security 为什么浏览器接受通过非安全（HTTP）连接发送的安全cookie？

当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）连接发送，并且它们始终设置了“secure”和“HttpOnly”属性
• 仅接受由站点生成并通过设置了“安全”属性的Cookie从客户端发送的会话标识符（网站不接受URL等的会话标识符）
• 通过在HTML表单上设置用户特定的令牌来保护CSRF，当用户提交POST请求时，服务器会检查该令牌
• 通过将所有输出为HTML的字符串正确编码来保护XSS
• 未实现HST，或用户浏览器不支持HST（如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，并不断浏览站点以保持会话活动。 然后，他还修改用户对

www.example.com

的HTTP请求，以在HTTP响应中包含攻击者刚刚从服务器获得的相同会话cookie。cookie设置了“安全”标志

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

稍后，用户登录到

https://www.example.com/

并希望登录。他查看地址栏以确保显示SSL图标，因为它是，所以使用他的密码登录。但是，由于攻击者先前通过在不安全的HTTP请求上发送具有“安全”属性的cookie来修复用户的会话，因此攻击者现在可以访问用户的会话状态

请注意，如果用户登录时网站正在更改会话标识符，攻击者将无法访问用户的会话状态，但攻击者仍有可能以自己的身份登录并将其会话cookie发送给用户，覆盖以前的会话/登录cookie，以便用户执行操作（如写敏感邮件等）代表攻击者

我对该浏览器行为的印象是，它引入了一个额外的会话固定场景，如上所述。防止这种情况发生的唯一方法是更改每个请求上的会话标识符（对于HTML页面）

我是不是遗漏了什么

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

• 在用户浏览器中插入会话cookie，并将其设置为浏览器将拒绝的“安全”属性，以及
• （编辑：不适用）在用户浏览器中插入未设置“安全”属性的会话cookie，因为网站将忽略未设置“安全”属性的cookie

这将消除特定网站在每次请求时更改会话标识符的需要

编辑：好的，我遗漏了一件事，浏览器似乎没有将Cookie头上的“Secure”属性发送回服务器，因此服务器无法确定此Cookie是否设置为具有“Secure”属性的客户端浏览器

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

有什么想法吗

---

谢谢！

没错，这是已知的安全标志限制。来自

然后从

我认为您最好的选择是不要过多地依赖cookies来满足安全相关的要求：b

是的，确切地说：“虽然看起来对保护cookies免受主动网络攻击者攻击很有用，但安全属性仅保护c

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).

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.