Cookies 的跨域脚本攻击 - Github 迁移域名的安全详解 已翻译 100%

葱油拌面 投递于 2013/04/11 09:49 (共 15 段, 翻译完成于 04-14)
阅读 11631
收藏 116
20
加载中

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

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

GoingHigh
GoingHigh
翻译于 2013/04/11 11:09
2

一个二级域名传过来的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来传输。
GoingHigh
GoingHigh
翻译于 2013/04/11 11:22
2

因此,从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设置在哪个域名上,比如路径或者域名。
GoingHigh
GoingHigh
翻译于 2013/04/11 11:43
1

最直接的跨域攻击涉及到:在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来自哪里。
GoingHigh
GoingHigh
翻译于 2013/04/11 12:00
1

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

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

免受cookie抛出的伤害

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

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

GoingHigh
GoingHigh
翻译于 2013/04/13 10:54
1

为了完成这个示例,我们创造了一个特殊的响应:我们让浏览器跳转到刚刚请求的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的攻击,但还有一些更复杂的攻击也需要我们思考一下.

GoingHigh
GoingHigh
翻译于 2013/04/13 11:17
1

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的迁移后,效果非常好.
GoingHigh
GoingHigh
翻译于 2013/04/13 11:37
1

Cookie溢出

让我们加强我们的游戏:另一种攻击将会执行,它利用RFC 6265没有明确指明一种cookie的溢出行为.大部分web服务器/接口,包括Rack,假定cookie的名字可以加密(如果他们包含不是ASCII的字符时,这就是个疯狂的假设),所以当生成cookie列表时不会溢出:

cookies = Utils.parse_query(string, ';,') { |s| Rack::Utils.unescape(s) rescue s } 
这就允许一个恶意用户去设置一个cookie,这个cookie能被web框架理解成_session,尽管在浏览器里这个cookie的名字并不是_session.这个攻击会把没必要溢出的cookie字符溢出掉:
GET / HTTP/1.1
Host: github.com
Cookie: logged_in=yes; _session=chocolate-cookie; _%73ession=bad-cookie;
{ "_session" : ["chocolate-cookie", "bad-cookie"] } 
GoingHigh
GoingHigh
翻译于 2013/04/13 11:55
1
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(9)

无用之竹

引用来自“_Leebai”的评论

译文有点糙啊,比如“通过JavaScript在二级域名上设置的cookie被发送旁边合法的cookie字段中,并设置到父域名里”,应为"子域用JS设置的cookie,跟在父域设置的合法cookie之后被发送";再如“第一个cookie将会被假定成任意值”,应为“第一个cookie将被武断地当成cookie的值”,这两句可是全文的核心。

顺着原文看了一下RFC6265,8.6小节: Weak Integrity,已经提到这个安全隐患,该发生的事情总会发生。。。。。。
难怪每次看到这里都懵了,看了英文有优点迷糊,谢谢。
GoingHigh
GoingHigh

引用来自“_Leebai”的评论

译文有点糙啊,比如“通过JavaScript在二级域名上设置的cookie被发送旁边合法的cookie字段中,并设置到父域名里”,应为"子域用JS设置的cookie,跟在父域设置的合法cookie之后被发送";再如“第一个cookie将会被假定成任意值”,应为“第一个cookie将被武断地当成cookie的值”,这两句可是全文的核心。

顺着原文看了一下RFC6265,8.6小节: Weak Integrity,已经提到这个安全隐患,该发生的事情总会发生。。。。。。

由于水平有限,所以有很多地方不准确,多谢指摘。但现在好像没法编辑译文了,不知道怎么修改啊
_Leebai
_Leebai
译文有点糙啊,比如“通过JavaScript在二级域名上设置的cookie被发送旁边合法的cookie字段中,并设置到父域名里”,应为"子域用JS设置的cookie,跟在父域设置的合法cookie之后被发送";再如“第一个cookie将会被假定成任意值”,应为“第一个cookie将被武断地当成cookie的值”,这两句可是全文的核心。

顺着原文看了一下RFC6265,8.6小节: Weak Integrity,已经提到这个安全隐患,该发生的事情总会发生。。。。。。
杜哲
为什么把escaping翻译成“溢出”呢?这不是“转义”的意思么
唐海康
唐海康
看不懂……
java9
java9
不错不错.
super0555
super0555
好文要支持
beves
beves
非常不错,顺带解释了那个315的很多东西
hnphper
hnphper
关注
返回顶部
顶部