为什么浏览器接受通过非安全(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)连接发送,并且它们始终设置"安全"和"HttpOnly"属性.

仅接受由站点生成并已通过具有"安全"属性集的Cookie从客户端发送的会话标识符(该网站不接受来自URL等的会话标识符)

通过在用户提交POST请求时由服务器检查的HTML表单上设置用户特定的标记来保护CSRF.

通过正确编码以HTML格式输出的所有字符串来保护XSS.

并没有实现HSTS,或在用户的浏览器不支持HSTS(如IE,Safari浏览器).

并没有改变它的会话标识符(会话cookie的值),当用户登录英寸

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

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

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

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

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

我对此浏览器行为的印象是它引入了如上所述的附加会话修复方案.我可以看到阻止这种情况的唯一方法是在每个请求上更改会话标识符(对于HTML页面).

我在这里错过了什么吗？

我的观点是,如果浏览器拒绝具有"安全"属性集但通过不安全的HTTP连接发送的cookie,攻击者将无法:

在用户的浏览器中注入一个会话cookie,其中设置了"安全"属性,因为浏览器会拒绝它,并且

(编辑:不适用)在用户的浏览器中注入会话cookie,该会话cookie没有设置"安全"属性,因为网站会忽略没有"安全"属性的cookie.

这将消除特定网站对每个请求更改会话标识符的需要.

编辑:好的,我遗漏的一件事是浏览器似乎没有将Cookie标头上的"安全"属性发送回服务器,因此服务器无法确定此cookie是否已设置到客户端的浏览器中"安全"属性.

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

有任何想法吗？

谢谢!