Cookies Lack Integrity: Real-World Implications

Xiaofeng Zheng, Tsinghua University; Jian Jiang, University of California, Berkeley; Jinjin Liang, Tsinghua University; Haixin Duan, Tsinghua University and International Computer Science Institute; Shuo Chen, Microsoft Research Redmond; Tao Wan, Huawei Canada; Nicholas Weaver, International Computer Science Institute and University of California, Berkeley

Security'15

摘要

cookie中如果包含一个“secure" flag，那么表示cookie只能在https连接中发送，但是并没有flag可以表明cookie是怎样被设置的。中间人或者是在相关域内的攻击者，可以在http session中进行cookie注入，这个cookie在后续的https连接中会被附加进去。

这个攻击是已知的，但是并没有被透彻研究过。这篇文章就对cookie injection攻击的实际影响进行了分析（empirical assessment），发现cookie相关的漏洞在Google，BOA等重要站点中都存在，并且一些主流浏览器（chrome、Firefox、Safari等）的实现不足会加重这一情况。文章成功的攻击包括隐私违背、线上欺骗、经济损失、账户劫持等。

文章最后给出了mitigation strategies（服务器端HSTS，可能的浏览器端更改），并实现了一个浏览器扩展，提供http和https间、相关域间的cookie更好隔离。

Introduction

同源策略在保护cookie时并不奏效:origin = scheme+domain+port，而cookie并不看scheme和port，对于domain的区分也很弱，不同但相关的domain会共享cookie scope。

secure flag只能保证confidentiality，并没有对应策略可以保证cookie的integrity。

尽管是已知的问题，但是这个问题带来的现实影响被低估。通过注入恶意cookie带来的攻击，很多是很难发现的但造成的后果很严重。文章关注攻击者如何才能发起cookie注入攻击，以及对现实世界中网站的破坏后果。

1. 对可能受cookie注入攻击影响的网站进行评估，包括hsts的情况和CDN用的共享域
2. 评估浏览器端和服务器端cookie实现
3. 表明现实中cookie注入攻击的严重性和盛行，对很多大型网站的利用表明cookie注入攻击会导致在不同实现、应用和已知攻击间的复杂交互
4. 实现浏览器端扩展，提供更好的cookie隔离，并具有兼容性
   总之，文章更深层次的描述了cookie完整性问题以及cookie注入的威胁。

Background

Cookies

设置可以是HTTP服务器通过set-cookie头，或者客户端javascript通过写document.cookie

五个可选属性：domain和path指定cookie的适用范围；expires表明过期时间；secure表明只能通过https发送；HTTPOnly阻止浏览器端脚本读

当向服务器发送请求时，浏览器会包括说有没有过期并且domain和path都和url匹配的cookie

cookie有两个不正常的行为：
1. cookie的存储和读出没有关联。cookie设置或存储时是按照name/domain/path-value格式，但是读出时却只读name-value
2. 在写cookie时，可以对path属性指定任意值

此外，同源策略对于cookie也不严格，除了上面提到的问题，cookie的域范围可以被网站设定为host-only，与子域名共享以及与兄弟域名共享。

cookie的读写不对称问题和缺少域/scheme区分问题的结合，会导致domain无法在有中间人或恶意相关域的情况下保证cookie的完整性，主要是两种情况：
1. cookie覆写，相关域覆盖原cookie（name/domain/path都一样），secure cookie可以被http连接写
2. cookie shadowing，name一样
“value=good;domain=www.example.com; path=/; secure”
“value=bad; domain=.example.com;path=/home”
when browser issues a request to https://www.example.com/home, both
cookies match the URL and are included. For most browsers, the cookie header will be “Cookie: value=bad; value=good;”.

cookie注入攻击

通过http回复包注入到后续https连接，从一个domain注入到相关domain
根本原因：对cookie的松散sop定义

08年，cookie forcing，利用cookie完整性缺陷重写https会话的cookie
13年，cookie tossing，github把放用户主页的域名github.com迁移到github.io，就是因为共享域的子域是属于相互间不信任的用户的。

学术上已有文章提出cookie-interity头来区分https和http设置的cookie，origin-cookie来提供完整的3元组SOP，Blackhat EU和AD中有关于cookie注入的几个巧妙攻击

Threat Analysis

另外当网站和其他不可信的网站共享同一域范围时，上述问题也存在

一个域允许cookie设置的范围更大，只要那个范围不是public的。那么就需要给public和non-public做界定。现实中有很多shared domain（比如cdn，blog，hosting providers），这些都应该被认为是public的。

有个叫做public suffix列表，但是从作者的实验结果来看，在alexa前一百万个网站中，作者识别出45个shared domain，其中只有10个Google domain和3个非Google domain在列表中。像sinaapp.com等域名，在其上的网站都会受cookie注入攻击。

另一个容易忽视的例子是cdn，尽管cdn上放的都是静态资源，但是仍旧可以造成严重后果。作者搜集了23个cdn用的28个shared domain，其中只有2个在上述列表中。作者成功注册并测试了12个cdn的13个shared domain。

过滤set-cookie无法阻止javascript
声明子域名为public，无法阻止customer-specific prefix

Cookie实现的问题

浏览器和web服务器中cookie实现的不一致问题

Vulnerabilities

处理代理response的脆弱性

对采用了full HSTS站点进行cookie注入攻击（在未加密的407响应中设置cookie，除IE外其他浏览器都接受）

Safari中处理public suffix

在请求http://tld/时，接受所有subdomains.tld的cookie

Safari的HSTS实现

Safari不对url进行percent-decoding和大写到小写转换，使得攻击者可能通过在域名中使用percent-decoding和大小写混写的方式，绕过hsts的检查

实际利用

Our study aims at understanding the prevalence and
severity of potential exploitation by cookie injection in
real-world websites. In particular, we are curious about
how web developers use cookies, whether they are aware
of this problem explicitly and have developed best practices
accordingly. With these questions in mind, we ...

cookie在实际中有三种用法：用作认证token；表明跟session无关的状态；reflected into HTML

Cookies as Authentication Token

Sub-session Hijacking攻击
防止方法：url与id-indicator相关；session dependent nonce binds seperate urls together

• case 1：Gmail chat gadget hijacking
• case 2：“Invisible” Google search history stealing
• Case-3: Credit card stealing on China UnionPay
• Case-4: Deposit hijacking on JD.com
• Case-5: Account hijacking against Google OAuth and BitBucket

Cookies as References to Session Independent States

associate important server-side states with long-term cookies，do not bind these states with user sessions.

• Case-6: Shopping cart tracking/manipulation on popular E-commerce websites.
• Case-7: Browsing history and purchase tracking/hijacking on Amazon

Cookies reflected into HTML

• Case-8: XSS via cookie injection on China Construction Bank, Amazon Cloud Drive, eBay and others.
• Case-9: Insufficient cookie validation on Bank of America.
• Case-10: BREACH attacks on phpMyAdmin and MediaWiki.

Possible Defenses

1. Full HSTS and Public Suffix List
2. Defensive Cookie Practices
3. Anomaly Detection