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

时间：2014-02-03 23:36:03

标签： security session cookies ssl

当IE 11，Firefox 26，Chrome 32等浏览器通过不安全（HTTP）连接接收Cookie时，该连接具有＆＃34; Secure＆＃34;指定的属性，它们存储cookie并在它们通过安全（HTTPS）连接向同一服务器发出请求后将其发回。

虽然这可能符合某些规范（我猜Netscape Cookies），但我想知道这是否会为SSL安全网站带来额外的安全漏洞（会话修复）。

考虑以下情况：

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

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

网站：

  • 通过SSL / TLS提供对其所有页面和资源的访问。这意味着一旦用户使用https访问页面，该页面上的每个内部链接都是https链接，这样他们就不会降级＆＃34;降级＆＃34;从HTTPS到HTTP的连接。它也不包含任何混合（HTTP / HTTPS）内容。
  • 如果用户通过HTTP访问其中一个页面，则会将用户从HTTP重定向到具有301状态代码的HTTPS。
  • 将登录信息存储在会话Cookie中。
  • 确保发送到客户端的所有Cookie（包括会话cookie）仅通过安全（HTTPS）连接发送，并且他们始终设置＆＃34; Secure＆＃34;和＃34; HttpOnly＆＃34;属性。
  • 只接受网站生成的会话标识符，并且已经通过具有＆＃34; Secure＆＃34;的Cookie从客户端发送。属性集（网站不接受来自URL等的会话标识符。）
  • 通过在用户提交POST请求时由服务器检查的HTML表单上设置用户特定的标记来保护CSRF。
  • 通过正确编码以HTML格式输出的所有字符串来保护XSS。
  • 不实施HSTS，或者用户的浏览器不支持HSTS（如IE，Safari）。
    • 当用户登录时，
  • 不更改会话标识符（会话Cookie的值）。

现在，假设攻击者运行一个拦截通过非安全HTTP请求发送的所有数据的程序，如果这些是HTML页面，请插入一个snipped，使浏览器向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具有＆＃34; Secure＆＃34;国旗集。

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

稍后，用户访问https://www.example.com/并想要登录。他查看地址栏以确保显示SSL图标，因为它是，使用他的密码登录。但是，因为攻击者通过发送带有＆＃34; Secure＆＃34;的cookie来固定用户的会话。对于先前不安全的HTTP请求的属性，攻击者现在可以访问用户的会话状态。

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

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

我在这里错过了什么吗？

我的观点是，如果浏览器拒绝具有＆＃34;安全＆＃34;属性集但是通过不安全的HTTP连接发送，攻击者无法：

  • 在用户的浏览器中注入会话cookie，其中包含＆＃34; Secure＆＃34;属性设置为浏览器会拒绝它，
  • （编辑：不适用）在用户的浏览器中注入会话cookie，该浏览器没有＆＃34;安全＆＃34;属性集，因为网站会忽略没有＆＃34;安全＆＃34;属性。

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

编辑：好的，我遗漏的一件事是浏览器似乎没有发送＆＃34;安全＆＃34;将Cookie标头上的属性返回给服务器，因此服务器无法确定此cookie是否已通过＆＃34; Secure＆＃34;设置到客户端的浏览器中。属性。

但这意味着，即使浏览器拒绝使用＆＃34; Secure＆＃34;在非SSL连接上标记，攻击者可以设置一个没有＆＃34; Secure＆＃34;然后，网站会在HTTPS请求中接受该标记，因为它无法检查＆＃34;安全＆＃34;饼干的旗帜。

有什么想法吗？

谢谢！

1 个答案:

答案 0 :(得分：6)

你是对的，这是安全标志的已知限制。来自http://tools.ietf.org/html/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).

然后从http://tools.ietf.org/html/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

相关问题
最新问题