Cookies 蓝冠注册平台的跨域脚本攻击 – Github 迁移域名的安全详解

上周五我们宣布并完成了把所有的GitHub页面迁移到新域名github.io。 这是个计划已久的行动,蓝冠注册平台 此举是为了防止恶意网站攻击和跨域cookie的漏洞,这些漏洞是通过在我们主站的子域名下控制客户内容产生的。

关于这些跨域攻击漏洞的可怕影响,蓝冠官网 大家可能会有一些困惑。我们希望这篇技术博客可以消除这些困惑。

一个二级域名传过来的Cookie
当你登陆GitHub.com时,我们通过响应的HTTP头部来设置session的cookie。这个cookie包含着唯一标识你的session数据:

Set-Cookie: _session=THIS_IS_A_SESSION_TOKEN; path=/; expires=Sun, 01-Jan-2023 00:00:00 GMT; secure; HttpOnly
这些GitHub发送给浏览器的session的cookie是设定在默认的域名上(github.com),这就意味着这些cookie是不能从二级域名*.github.com访问到的。而且我们也指定了HttpOnly属性,这意味着cookie也不能通过JavaScript 的API:document.cookie来读取。最后,我们指定了Secure属性,这意味着这些cookie只能通过HTTPS来传输。

因此,从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的攻击,但还有一些更复杂的攻击也需要我们思考一下.

分享到:
No Response
Comment (0)
Trackback (0)