阅读 1527

我遇过的最难的 Cookie 问题

GitHub 原文鏈結,繁體中文版)

前言

几个礼拜前我在工作上碰到了一些跟 Cookie 有关的问题,在这之前,我原本想说:Cookie 不就那样嘛,就算有些属性不太熟悉,上网找一下资料就好了,哪有什麽跟 Cookie 有关的难题?

然而事实证明我错了。我还真的碰到了一个让我解超久的 Cookie 问题。

相信看到这边,很多人应该跃跃欲试了,那我就先来考一下大家:

什麽情形下,Cookie 会写不进去?

像是语法错误那种显而易见的就不用说了,除此之外你可能会答说:写完全不同 domain 的 Cookie。例如说你的网页在 http://a.com 却硬要写 http://b.com 的 Cookie,这种情形当然写不进去。

或者,你可能会回答:不在 https 却想加上 Secure flag 的 Cookie。
没错,像是这种情形也会写不进去。

除了这些,你还能想到什麽吗?

如果想不太到,那就听我娓娓道来吧!

悲剧的开始

在一个月前我写了一篇跟 CSRF 有关的文章(让我们来谈谈 CSRF),正是因为工作上需要实作 CSRF 的防御,所以趁机研究了一下。简单来说,就是要在 Cookie 设置一个 csrftoken

可是那天我却发现,我怎麽写都写不进去。

我的测试网站的网址是:http://test.huli.com,拿来写 Cookie 的 script 是:

document.cookie = "csrftoken=11111111; expires=Wed, 29 Mar 2020 10:03:33 GMT; domain=.huli.com; path=/"
复制代码

我就只是想对.huli.com写一个名称是csrftoken的 Cookie。而我碰到的问题,就是怎麽写都写不进去。

这段语法完全没有问题,我检查过好几遍了,但就是不知道为什麽写不进去。我们开头讲的那几种 case 这边都完全没碰到。这只是一个简单的 http 网站,而且是写自己 domain 的 Cookie,怎麽会写不进去?

刚开始碰到这情形,我还想说会不会是我电脑的灵异现象,在其他人的电脑上就好了,就暂时没有管它,直到有一天 PM 跟我说:「咦,这个页面怎麽坏了?」,我仔细检查后才发现是因为他也写不进去这个 Cookie,导致 server 没有收到 csrftoken 而验证失败。

好了,看来现在已经确认不是我电脑上的问题了,而是大家都会这样。可是,却有其他人是正常的。其他人都可以,但就只有我跟 PM 两个人不行。

幸好见过小风小浪的我知道,每次碰到这种诡异的问题,先开无痕模式再说,至少可以知道你的浏览器不会被其他因素给干扰。打开无痕模式之后发现,可以了,可以设定 Cookie 了。在一般情况下不行设定,但是开无痕浏览模式却可以。

这就真的很奇怪了,到底为什麽不行呢?而且若是我把 Cookie 换了一个名字,叫做csrftoken2,就可以写入了!就唯独csrftoken这个名称不行,可是 Cookie 总不可能有保留字这种东西吧!就算真的有,csrftoken也绝对不会是保留字。

这一切都太诡异了,到底csrftoken这个名字有什麽问题?到底为什麽写不进去?

于是我就去拜了 Google 大神,用cookie 不能写cookie can not setunable set cookie等等的关键字去搜寻,却都一无所获,找到的答案都跟我的情况完全不一样。

我用 Chrome devtool 看了,明明http://test.huli.com就没有任何的 Cookie,怎麽会写不进去呢?

在经历过一阵乱找资料之后,我还稍微去翻了 cookie 的 rfc:HTTP State Management Mechanism,但还是没有找到相关资料。

最后不知道哪来的灵感,我就去 Chrome 的设定那边检视所有 huli.com 的 Cookie,并且一个一个看过之后删掉。删完之后,就可以正常写入 Cookie 了。

仔细想想其实还满合理的,毕竟无痕模式可以,就代表是以前做的一些事情会影响到写 Cookie 这件事,再经由删除 Cookie 就可以确认问题一定是出在其他有关的 Domain 身上,推测是其他 Domain 做了一些事情,才会造成 http://test.huli.com 没办法写入 Cookie。

后来我回想起刚刚删掉的那几个 Cookie,发现存在一个也叫做csrftoken的同名 cookie。

拨云见日

难得让我找到了一点线索,当然要跟着这条线索继续查下去。

回想了一下,发现是另外一个负责后台管理的网站叫做:https://admin.huli.com写的,因为是用 django 的关係,所以开启 CSRF 防护之后预设的 Cookie 名称就是csrftoken

仔细再用 Chrome devtool 看了一下,这个 Cookie 设置了Secure,Domain是 .admin.huli.com。看起来也没什麽异状。

然而,在拜访这个网站之后,我再试着去 http://test.huli.com,发现又没办法写入 Cookie 了,甚至原本的 Cookie 也离奇地消失了。

太棒了!看来我离真相越来越近了!

我把这个.admin.huli.com的同名 Cookie 删掉之后,去拜访我自己的http://test.huli.com,发现一切都正常。Cookie 可以正常写入。

看来答案很明显了,那就是:

只要.admin.huli.com的那个同名 Cookie 存在,http://test.huli.com就没办法对.huli.com写入同名的 Cookie。

解法其实到这边就很明显了,第一个是改一个 Cookie 名称,第二个是改一个 Domain。

有关于第二个解法,还记得我们在 http://test.huli.com 是写入 .huli.com 这个 Domain 的 Cookie 吗?只要改成写入 .test.huli.com 这个 Domain,一样可以正常运作。

所以若是讲得更详细一点,这个写不进去 Cookie 的问题就发生在:

当有一个 Domain 为.admin.huli.com并设置成Secure的 Cookie 已经存在的时候,http://test.huli.com就没办法对.huli.com写入同名的 Cookie。

在大概确认问题以后,我就开始调整各个变因,看能不能查出到底是哪一个环节出了问题,最后我发现两个重点:

  1. 其实只有 Chrome 不能写,Safari, Firefox 都可以
  2. Secure 这个 flag 没有设置的话,就可以写

深入追查

既然有了只有 Chrome 会发生这种情形的这个有力线索,就可以循着这条线继续追查下去,那怎麽追查呢?

没错,就是最简单直接的方法:去找 Chromium 的原始码!

以前看过很多文章都是查问题查一查最后查到 Source code 去,终于轮到我也有这一天了。可是 Chromium 的原始码这麽一大包,该如何找起呢?

于是我决定先 Google:chromium cookie,在第一笔搜寻结果发现了很有帮助的资料:CookieMonster。这篇文章有详细说明了 Chromium 的 Cookie 机制是怎麽运作的,并且说明核心就是一个叫做 CookieMonster 的东西。

再来就可以直接去看 Source code 了,可以在 /net/cookies 找到 cookie_monster.cc

还记得刚刚发现的问题重点之一,推测是跟Secure这个 flag 有关,所以直接用 Secure 当关键字下去搜寻,可以在中间的部分发现一个 DeleteAnyEquivalentCookie 的 function,以下节录部分原始码,1146 行到 1173 行:

// If the cookie is being set from an insecure scheme, then if a cookie
// already exists with the same name and it is Secure, then the cookie
// should *not* be updated if they domain-match and ignoring the path
// attribute.
//
// See: https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone
if (cc->IsSecure() && !source_url.SchemeIsCryptographic() &&
    ecc.IsEquivalentForSecureCookieMatching(*cc)) {
  skipped_secure_cookie = true;
  histogram_cookie_delete_equivalent_->Add(
      COOKIE_DELETE_EQUIVALENT_SKIPPING_SECURE);
  // If the cookie is equivalent to the new cookie and wouldn't have been
  // skipped for being HTTP-only, record that it is a skipped secure cookie
  // that would have been deleted otherwise.
  if (ecc.IsEquivalent(*cc)) {
    found_equivalent_cookie = true;
    if (!skip_httponly || !cc->IsHttpOnly()) {
      histogram_cookie_delete_equivalent_->Add(
          COOKIE_DELETE_EQUIVALENT_WOULD_HAVE_DELETED);
    }
  }
} 
复制代码

这边很贴心的帮你加上了注释,说是:

如果有个 cookie 是来自 insecure scheme,并且已经存在一个同名又设置为 Secure 又 domain-match 的 cookie 的话,这个 cookie 就不该被设置

虽然不太理解 domain-match 指的到底是怎样才算 match,但看来我们碰到的写不进去 Cookie 的问题就是在这一段发生的。而且还有贴心附上参考资料:tools.ietf.org/html/draft-… 标题为:「Deprecate modification of 'secure' cookies from non-secure origins」。

内容不长,很快就可以看完,以下节录其中一小段:

Section 8.5 and Section 8.6 of [RFC6265] spell out some of the
drawbacks of cookies' implementation: due to historical accident,
non-secure origins can set cookies which will be delivered to secure
origins in a manner indistinguishable from cookies set by that origin
itself.  This enables a number of attacks, which have been recently
spelled out in some detail in [COOKIE-INTEGRITY].
复制代码

附注中的参考资料是这个:Cookies Lack Integrity: Real-World Implications,裡面有附一段二十几分钟的影片,可以看一看,看完之后就会知道为什麽不能写入了。

如果你还没看,这边可以帮大家做一个总结。要知道为什麽刚开始那个 case 不能写入 Cookie,可以先想想看如果可以写入,会发生什麽事情。

假如 http://test.huli.com 成功写入 .huli.comcsrftoken 这个 cookie 的话,对 http://test.huli.com 似乎没什麽影响,就多带一个 Cookie 上去,看起来合情合理。

可是呢,却对 https://admin.huli.com 有些影响。

原本 .admin.huli.com 并且设置为 Secure 的 Cookie 还是会在,但现在多了个 .huli.com 又是同名的 Cookie。当 https://admin.huli.com 送 request 的时候,就会把这两个 Cookie 一併带上去。所以 Server 收到的时候可能会是这样:

csrftoken=cookie_from_test_huli_com; csrftoken=cookie_from_admin_huli_com
复制代码

但碰到同名 Cookie 的时候,很多人都会只取第一个处理,所以 Server side 收到的 csrftoken 就会是 cookie_from_test_huli_com

意思就是说,儘管你在 https://admin.huli.comSecure 的方式写了一个 Cookie,却被其他不安全的来源(http://test.huli.com)给复盖过去了!

那盖掉 Cookie 可以做什麽呢?举几个上面参考资料给的例子(但我不确定有没有理解错误,有错的话请指正),第一个是 Gmail 的视窗不是分成两部分吗,一部分是信箱,另外一部分是 Hangouts。攻击者可以利用上面讲的手法把原来使用者的 cookie 盖掉,换成自己的 session cookie,可是因为 Hangouts 跟 Gmail 本身的 domain 不一样,所以 Gmail 还是使用者的帐号,Hangouts 却已经变成攻击者的帐号了。

被攻击的人就很有可能在不知情的状况下利用攻击者的帐号来发送讯息,攻击者就可以看到那些讯息了。

第二个例子是某间银行网站,假如在使用者要新增信用卡的时候把 session cookie 换成攻击者的,那这张信用卡就新增到攻击者的帐户去了!

大概就是这样,总之都是透过把原本的 cookie 遮蔽住,让 server side 使用新的 cookie 的攻击方法。

总结

我一开始碰到这个问题的时候真的满苦恼的,因为怎麽想都想不到为什麽一个语法完全没错的指令没办法写入 Cookie,而且https://admin.huli.com这个网站我平常也很少用到,根本不会想到是它的问题。

但这次把问题解掉之后重新回来看,其实过程中就有一些蛛丝马迹可循,例如说可以透过「清掉 Cookie 就没事」这点得知应该是跟其他 Cookie 有干扰,也可以从别的浏览器可以写入这点得知应该是 Chrome 的一些机制。

过程中的每个线索都会带你找到新的路,只要坚持走下去,一定能成功闯出迷宫。

关注下面的标签,发现更多相似文章
评论