Github迁移域名的安全详解

因此，从GitHub托管网站读取或"窃取"session的cookie是不太可能的。通过在GitHub网站托管的用户代码是不容易获取到session的cookie，但由于浏览器通过HTTP请求来发送cookie，这种方式有可能把cookie从GitHub网站抛到GitHub父域名上。

当浏览器执行一个HTTP请求时，它通过header里单 独的cookie发送一些和URL匹配的cookie，这些发送的cookie是以键-值对存在的。只有和请求的URL匹配的cookie才会发送出去， 比如，当执行一个对github.com的请求时，设置在域名github.io上的cookie是不会发送的，但在github.com上的 cookie将会发送。

GET / HTTP/1.1 Host: github.com Cookie: logged_in=yes; _session=THIS_IS_A_SESSION_TOKEN;

Cookie抛出的问题是因为header中的cookie只包含了一系列键值对的cookie，并没有一些其他信息， 通过这些额外信息可以知道cookie设置在哪个域名上，比如路径或者域名。

最直接的跨域攻击涉及到：在GitHub托管网站页面，通过document.cookie这个JavaScript API设置一个_session的cookie。假设这个网站托管在*.github.com，那么这个cookie将会被设置到父域名的所有请求里，尽管事实是它只设置在了二级域名里。

/* set a cookie in the .github.com subdomain */ document.cookie = "_session=EVIL_SESSION_TOKEN; Path=/; Domain=.github.com"

GET / HTTP/1.1 Cookie: logged_in=yes; _session=EVIL_SESSION_TOKEN; _session=THIS_IS_A_SESSION_TOKEN; Host: github.com

在这个示例中，通过JavaScript在二级域名上设置的cookie被发送旁边合法的cookie字段中，并设置到父域名里。如果域名，路径，Secure和HttpOnly属性未设置的话，根本 没有方法去判断哪个cookie来自哪里。

这对大部分web服务器来说是一个大问题，因为在一个域及其子域中的cookies的顺序并不是有RFC6265指定的，并且web浏览器可以选择以任何顺序发送它们。

对于Rack--为Rails和Sinatra提供动力的web服务器界面，包括其他的，cookis解析如下：

def cookies hash = {} cookies = Utils.parse_query(cookie_header, ';,') cookies.each { |k,v| hash[k] = Array === v ? v.first : v } hash end

如果在Cookie:header里有不止一个有着相同名字的cookie时，第一个cookie将会被假定成任意值。

这是一个很显而易见的攻击:几周之前,安全专家Egor Homakov在博客中就用这个方法证明了该攻击确实存在.这个漏洞的影响是不严重的(每次登录后,跨站点伪造请求的令牌会被重置,所以它们不会一直固定 不变),但这是个非常实际的例子,人们可以很容易伪造注销用户,令人很郁闷.这使得我们必须尽快完成把GitHub页面迁移的他们自己的域名,但只留给我 们几周的时间(到迁移完成之前),在这期间我们必须减轻已知的攻击数量.

幸运的是,已知的攻击在服务端很容易减轻.我们预想到会有一些其他的攻击,这些攻击或者很难处理,或者根本不可能存在.那么让我们一起看看这些它们.
 

免受cookie抛出的伤害

第一步是减轻cookie抛出造成的攻击.这个攻击暴露出浏览器将会发送2个相同名字的cookie令牌,不让我们知道它们是设置在哪个域名上的.

我 们没法判断每个cookie是来自哪里的,但如果我们跳过cookie的解析,我们就能看出每个请求是否包含2个相同的_session的cookie. 这个极有可能是由于有些人从二级尝试域名抛出这些cookie,所以我们不是猜测哪个cookie是合法的,哪个是被抛过来的,而是简单地通知浏览器在继 续执行之前放弃二级域名上设置的cookie.

为了完成这个示例,我们创造了一个特殊的响应:我们让浏览器跳转到刚刚请求的URL,但带着一个Set-Cookie的header,这个header放弃了二级域名上的cookie.

 

GET /libgit2/libgit2 HTTP/1.1 Host: github.com Cookie: logged_in=yes; _session=EVIL_SESSION_TOKEN; _session=THIS_IS_A_SESSION_TOKEN;

HTTP/1.1 302 Found Location: /libgit2/libgit2 Content-Type: text/html Set-Cookie: _session=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; Path=/; Domain=.github.com;

我们决定按照Rack中间件来实现这个功能.这种方式在 应用运行之前可以执行检查cookie和顺序重定向的工作.

当触发Rack的中间件时,在用户不会意识到的情况下,这个重定向会自动发生,并且第二个请求将只会包含一个_session的cookie:合法的那一个.

这个"破解"足够减缓大部分人所遇到的直接抛出cookie的攻击,但还有一些更复杂的攻击也需要我们思考一下.

Cookie路径方案

如果一个恶意的cookie设置到一个具体的路径,这个路径不是根路径(例如,/notifications),当用户访问github.com/notifications时,浏览器会发送那个cookie,当我们在根路径上清除这个cookie时,我们的header不会起作用.

 

document.cookie = "_session=EVIL_SESSION_TOKEN; Path=/notifications; Domain=.github.com"

GET /notifications HTTP/1.1 Host: github.com Cookie: logged_in=yes; _session=EVIL_SESSION_TOKEN; _session=THIS_IS_A_SESSION_TOKEN;

HTTP/1.1 302 Found Location: /notifications Content-Type: text/html # This header has no effect; the _session cookie was set # with `Path=/notifications` and won't be cleared by this, # causing an infinite redirect loop Set-Cookie: _session=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; Path=/; Domain=.github.com;

这个方案非常直截了当,虽然不太雅:对于任何指定的请求URL,如果其路径部分匹配请求的URL,浏览器将只会发送一个恶意的JavaScript cookie.所以我们只需要在每个路径的元素上放弃这个cookie就可以了.

 

HTTP/1.1 302 Found Location: /libgit2/libgit2/pull/1457 Content-Type: text/html Set-Cookie: _session=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; Path=/; Domain=.github.com; Set-Cookie: _session=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; Path=/libgit2; Domain=.github.com; Set-Cookie: _session=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; Path=/libgit2/libgit2; Domain=.github.com; Set-Cookie: _session=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; Path=/libgit2/libgit2/pull; Domain=.github.com; Set-Cookie: _session=; Expires=Thu, 01-Jan-1970 00:00:01 GMT; Path=/libgit2/libgit2/pull/1457; Domain=.github.com;

当谈到cookie时,我们需要在服务端做关联.我们唯一目的是用这个强力方式清楚那些cookie,这种方式虽然暴力,但完成github.io的迁移后,效果非常好.