1. Cookies Lack Integrity: Real-World Implications Xiaofeng Zheng (1), Jian Jiang (2), Jinjin Liang (1), Haixin Duan (1,3), Shuo Chen (4), Tao Wan (5) and Nicholas Weaver (2,3) (1) Tsinghua University (2) University of California, Berkeley (3) International Computer Science Institute (ICSI) (4) Microsoft Research Redmond (5) Huawei Canada

2. A Case of Online Banking Hijacking A demo video – https://drive.google.com/file/d/0B0D- yqITYZ2kelhGS2swTFRsWEk/view The attack could happened even if –Only doing online banking at home (network is secure); –No phishing; –No malware infection; –… Unfortunately, you might go to a Starbucks weeks ago, opened some unecrypted news website –a malicious cookie is injected in your browser.

3. A Case of Online Banking Hijacking A demo video – https://drive.google.com/file/d/0B0D- yqITYZ2kelhGS2swTFRsWEk/view The attack could happen even if –Only doing online banking at home (network is secure); –No phishing; –No malware infection; –… Unfortunately, you might go to a Starbucks weeks ago, opened some unecrypted news website –a malicious cookie is injected in your browser.

4. A Case of Online Banking Hijacking A demo video – https://drive.google.com/file/d/0B0D- yqITYZ2kelhGS2swTFRsWEk/view The attack could happen even if –Only doing online banking at home (network is secure); –No phishing; –No malware infection; –… Unfortunately, you might went to a Starbucks weeks ago, opened some unecrypted news website –a malicious cookie was injected in your browser.

5. Background

6. How Cookie Works Interface: a key-value like browser-side storage to maintain states –Write: setcookie(name, value, expire, path, domain, secure, httponly) –Read: $_COOKIE[name] Protocol:

7. How Cookie Works Interface: a key-value like browser-side storage to maintain states –Write: setcookie(name, value, expire, path, domain, secure, httponly) –Read: $_COOKIE[name] Protocol: http://login.example.com/ Set-Cookie: user=alice; domain=“.example.com”; path=/; … Write as a response header

8. How Cookie Works Interface: a key-value like browser-side storage to maintain states –Write: setcookie(name, value, expire, path, domain, secure, httponly) –Read: $_COOKIE[name] Protocol: http://login.example.com/ Set-Cookie: user=alice; domain=“.example.com”; path=/; … key value Write as a response header Stored as key-value

9. How Cookie Works Interface: a key-value like browser-side storage to maintain states –Write: setcookie(name, value, expire, path, domain, secure, httponly) –Read: $_COOKIE[name] Protocol: http://login.example.com/ Set-Cookie: user=alice; domain=“.example.com”; path=/; … http://www.example.com/ Cookie: user=alice; … key value Write as a response header Stored as key-value Matches cookie domain and path with the URL, Only sends name-value pairs of all matching cookies.

10. Cookie’s Weak Access Control Policy In the same origin policy of web, the origin is usually defined by protocol, domain, and port, isolating static/active content from different websites. The origin of cookie only includes domain. In addition, two domains have same suffix, they may have shared cookie scope as the suffix. –Allows cross-domain and cross-scheme (HTTP to HTTPS) cookie injection. https://good.example.com/http://evil.example.com/

11. Cookie’s Weak Access Control Policy In the same origin policy of web, the origin is usually defined by protocol, domain, and port, isolating static/active content from different websites. The origin of cookie only includes domain. In addition, if two domains share same suffix, the suffix may be used as cookie scope and is accessible by both domains. –Allows cross-domain and cross-scheme (HTTP to HTTPS) cookie injection. https://good.example.com/http://evil.example.com/ Set-Cookie: value=bad; domain=.example.com

12. Cookie Overwriting A cookie can be directly overwritten if its domain scope is shared with an attacker from a related domain. value=good; domain=.example.com; path=/; secure http://evil.example.com/ value=bad; domain=.example.com; path=/

13. Cookie Overwriting A cookie can be directly overwritten if its domain scope is shared with an attacker from a related domain. value=bad; domain=.example.com; path=/ http://evil.example.com/

14. Cookie Overwriting A cookie can be directly overwritten if its domain scope is shared with an attacker from a related domain. value=bad; domain=.example.com; path=/ https://good.example.com/ Cookie: value=bad;

15. Cookie Shadowing Even a cookie is set with a more-specific domain, it still could be shadowed by a related domain attacker. value=good; domain=good.example.com; path=/; secure http://evil.example.com/ value=bad; domain=.example.com; path=/home

16. Cookie Shadowing Even a cookie is set with a more-specific domain, it still could be shadowed by a related domain attacker. value=good; domain=good.example.com; path=/; secure http://evil.example.com/ value=bad; domain=.example.com; path=/home

17. Cookie Shadowing Even a cookie is set with a more-specific domain, it still could be shadowed by a related domain attacker. value=good; domain=good.example.com; path=/; secure value=bad; domain=.example.com; path=/home https://good.example.com/home Cookie: value=bad; value=good

18. Cookie Shadowing Even a cookie is set with a more-specific domain, it still could be shadowed by a related domain attacker. value=good; domain=good.example.com; path=/ value=bad; domain=.example.com; path=/home https://good.example.com/home Cookie: value=bad; value=good … // return the first cookie with given name for (int i=0; i<cookies.length; i++) { if (cookies[i].getName().equals(name)) return cookies[i]; } …

19. A Known, Yet Overlooked Problem The problem is known. –Reported as early as 2004 [Johnston & Moore, 2004]. –Noted in current cookie specification [Barth, 2011]. –Several publications from academia and industry [Barth el.al., CCS’08][Evans, 2008][Singh et.al, S&P’10][Bortz et.al., W2SP’11] [Lundeen et.al., BHAD’11][Zalewski, 2012][Lundeen, BHEU’13][Github, 2013]. But, we feel that it is overlooked. –Not been addressed, or even serious responded by industry. –The awareness seems quite low comparing to other web attacks. –Not been study deeply, given the importance of cookie. –A particularly uncomfortable fact: It undermines the meaning of HTTS indicator!

20. Motivation To understand the real-world impact of cookie injection attacks. –In practice, how could an attacker inject malicious cookies into an HTTP/HTTPS session? –What kind of attacks could be caused by injecting cookies? –What should we do? are there possible protocol changes to improve cookie's integrity while not to break existing websites?

21. How could cookie injection happends ?

22. Cookie Injection Attackers in Practice Active network attackers, e.g, MITM at open wireless networks –controls targeted browser to issue an un-encrypted request to a fake subdomain, then inject cookies. e.g., an iframe of http://nonexistent.www.google.com/ to inject cookies with domain scope “.google.com” Web attackers, e.g, malicious customers of shared domains –cloud hosting providers assigning subdomains to users e.g., appspot.com –CDNs e.g., akamai.net

23. Mitigating Active Network Attackers Mitigation: browser never issues un-encrypted request to any related domain. –HSTS: HTTP Strict Transport Security, a response header –must be full HSTS: enabled on “top-level” domain with the includeSubDomains option: insufficient: “strict-transport-security: … includeSubDomains” on accounts.google.com sufficient: “strict-transport-security: … includeSubDomains” on google.com Deployment –IE11 starts to support HSTS since June 2015 –Full HSTS: Only 8 in top 1000, 1252 in top 1 million websites !

24. Mitigating Active Network Attackers Mitigation: browser never issues un-encrypted request to any related domain. –HSTS: HTTP Strict Transport Security, a response header –must be full HSTS: enabled on “top-level” domain with the includeSubDomains option: insufficient: “strict-transport-security: … includeSubDomains” on accounts.google.com sufficient: “strict-transport-security: … includeSubDomains” on google.com Deployment –IE11 starts to support HSTS since June 2015 –Full HSTS: Only 8 in top 1000, 1252 in top 1 million websites !

25. Mitigating Active Network Attackers Mitigation: browser never issues un-encrypted request to any related domain. –HSTS: HTTP Strict Transport Security, a response header –must be full HSTS: enabled on “top-level” domain with the includeSubDomains option: insufficient: “strict-transport-security: … includeSubDomains” on accounts.google.com sufficient: “strict-transport-security: … includeSubDomains” on google.com Deployment –IE11 starts to support HSTS since June 2015 –Full HSTS: Only 8 in top 1000, 1252 in top 1 million websites !

26. Mitigating Active Network Attackers Mitigation: browser never issues un-encrypted request to any related domain. –HSTS: HTTP Strict Transport Security, a response header –must be full HSTS: enabled on “top-level” domain with the includeSubDomains option: insufficient: “strict-transport-security: … includeSubDomains” on accounts.google.com sufficient: “strict-transport-security: … includeSubDomains” on google.com Deployment –IE11 starts to support HSTS since June 2015 –Full HSTS: Only 8 in top 1000, 1252 in top 1 million websites !

27. Mitigating Web Attackers Mitigation: let browser knows that shared domains cannot be used to set cookies. –The public suffix list: https://publicsuffix.org/, an exceptional list including TLDs, TLD-reserved domains, and self-declared shared domains. Deployment –Implemented by major browsers –Many shared domain providers are unaware of sinaapp.com, weebly.com, … only 2 out of 28 shared domains used by CDNs !

28. Mitigating Web Attackers Mitigation: let browser knows that shared domains cannot be used to set cookies. –The public suffix list: https://publicsuffix.org/, an exceptional list including TLDs, TLD-reserved domains, and self-declared shared domains. Deployment –Implemented by major browsers –Many shared domain providers are unaware of sinaapp.com, weebly.com, … only 2 out of 28 shared domains used by CDNs !

29. Mitigating Web Attackers Mitigation: let browser knows that shared domains cannot be used to set cookies. –The public suffix list: https://publicsuffix.org/, an exceptional list including TLDs, TLD-reserved domains, and self-declared shared domains. Deployment –Implemented by major browsers –Many shared domain providers are unaware of sinaapp.com, weebly.com, … only 2 out of 28 shared domains used by CDNs !

30. What could happen with non-public- suffix CDN share domain ? We cannot underestimate the threat of cookie injection from CDN shared domains, even they are only used for static resource files. http://evil.cdn.net/ c1=…; domain=.cdn.net; path=/foo/main.js https://good.cdn.net/foo/main.js Cookie: c1=..; c2=…; … 431: Header too large !

31. Implementation Made Worse A number of vulnerabilities and exploitable behaviors in cookie implementations –e.g., Chrome, Safari, Firefox, Opera make similar mistakes when handling 407 response from a proxy Makes cookie injection from active network attacker possible even full HSTS is deployed, when browser using proxy

32. What kind of attacks could be caused by cookie injection ?

33. Attacks Caused by Cookie Injection Do websites use cookies safely ? No We found a number of attacks with serious consequences on large websites –Payment/Deposit hijacking –Account hijacking –History stealing –… The attack cases demonstrates two points: –Developers are largely unaware of the problem. –Cookie injection potentially connects to a variety of known attacks. Maybe other form of attacks, hard to enumerate.

34. Case-1: Hijacking Gmail Chat Window https://mail.google.com/a https://chat.google.com/b

35. Case-1: Hijacking Gmail Chat Window https://mail.google.com/a https://chat.google.com/b sessioncookie; domain=“chat.google.com”; path=/b

36. Case-1: Hijacking Gmail Chat Window https://mail.google.com/a https://chat.google.com/b sessioncookie; domain=“chat.google.com”; path=/b

37. Case-1: Hijacking Gmail Chat Window https://mail.google.com/a https://chat.google.com/b sessioncookie; domain=“chat.google.com”; path=/b The attacker can selectively shadow session cookies to attribute certain activities to the attacker.

38. Case-2: XSS on BankofAmerica (fixed) https://secure.boa.com/login secure.boa.com/myaccounts Cookie: value=good; “/login”: 1. Cookie Validation 2. Set Cookie with “/login”, redirection ---------------------------------------------------- “/myaccounts”: 1. Read Cookie from “/myaccounts” Set-Cookie: value=good;path=“/”

39. Case-2: XSS on BankofAmerica (fixed) https://secure.boa.com/login secure.boa.com/myaccounts Cookie: value=good; Set-Cookie: value=good;path=“/” “/login”: 1. Cookie Validation 2. Set Cookie with “/login”, redirection ---------------------------------------------------- “/myaccounts”: (Cookie Validation missed!) 1. Read Cookie from “/myaccounts”

40. Case-2: XSS on BankofAmerica (fixed) https://secure.boa.com/login secure.boa.com/myaccounts Cookie: value=xss; value=good; Set-Cookie: value=good;path=“/” clean cookie with path “/” xss payload cookie with path “/myaccounts” “/login”: 1. Cookie Validation 2. Set Cookie with “/login”, redirection ---------------------------------------------------- “/myaccounts”: (Cookie Validation missed!) 1. Read Cookie from “/myaccounts” Every request may bring different cookie values, no matter how you set cookies previously.

41. Case-3: Side-Channel Leakage Cookie injection enables various ways to control encrypted traffic. –a vector of the BREACH attack [Gluck et.al, BH’13] –connects to the HTTPS size side-channel [Chen et.al.,S&P’10]

42. Case-3: Side-Channel Leakage Cookie injection enables various ways to control encrypted traffic. –a vector of the BREACH attack [Gluck et.al, BH’13] –connects to the HTTPS size side-channel [Chen et.al.,S&P’10] 1KB cookie with path “/sensitive_url1” 2KB cookie with path “/sensitive_url1” https://a.com/sensitive_url1; 1KB cookie https://a.com/sensitive_url2; 2KB cookie

43. Attacks Caused by Cookie Injection Do websites use cookie safely? No. We found a number of attacks with serious consequences on large websites –History stealing –Account hijacking –Payment/Deposit hijacking –… These cases demonstrate two points: –Web developers are largely unaware of the problem. –Cookie injection potentially connects to a variety of known attacks. may be other form of attacks, hard to enumerate its bad effects.

44. What should we do ?

45. Mitigations Shared domain providers –awareness of the public suffix list. Website development/deployment –be careful with cookies. –full HSTS Lack of isolation in cookie policy is root cause –possible to change cookie policy of browser ?

46. Exploration of Cookie Policy Change Isolate HTTPS and HTTP cookies –Breaks mix-content websites Isolate “secure” cookies from HTTP –One broken case of logout from HTTP Only allow “secure” cookies to be cleaned from HTTP –No broken cases found

47. Exploration of Cookie Policy Change Isolate HTTPS and HTTP cookies –Breaks mix-content websites Isolate “secure” cookies from HTTP –One broken case: logout from HTTP wants to clean “secure” session cookies. Only allow “secure” cookies to be cleaned from HTTP –No broken cases found

48. Exploration of Cookie Policy Change Isolate HTTPS and HTTP cookies –Breaks mix-content websites Isolate “secure” cookies from HTTP –One broken case: logout from HTTP wants to clean “secure” session cookies. Only allow “secure” cookies to be cleaned from HTTP –No broken cases found

49. Conclusions We should pay more attention on the problem of cookie integrity. –conservative use of cookies –awareness of the public suffix list check if your website is using shared domains that are not present on the list. –full HSTS, instead of HTTPS ! advocate and facilitate the deployment. Browsers may consider to enhance cookie isolation policy.

50. Thank you! Questions?