The Cracked Cookie Jar: HTTP Cookie Hijacking and the Exposure of Private Information

Total Page:16

File Type:pdf, Size:1020Kb

The Cracked Cookie Jar: HTTP Cookie Hijacking and the Exposure of Private Information The Cracked Cookie Jar: HTTP Cookie Hijacking and the Exposure of Private Information Suphannee Sivakorn∗, Iasonas Polakis∗ and Angelos D. Keromytis Department of Computer Science Columbia University, New York, USA fsuphannee, polakis, [email protected] ∗Joint primary authors Abstract—The widespread demand for online privacy, also the necessity of securing web connections from prying eyes. fueled by widely-publicized demonstrations of session hijacking The publicity garnered by the Firesheep extension [1], which attacks against popular websites, has spearheaded the increasing demonstrated how easily attackers can hijack a user’s session, deployment of HTTPS. However, many websites still avoid ubiq- uitous encryption due to performance or compatibility issues. The was a catalyst in expediting migration of critical user activity prevailing approach in these cases is to force critical functionality to mandatory HTTPS connections in major services (e.g., and sensitive data access over encrypted connections, while transmitting user credentials during the log-in process). allowing more innocuous functionality to be accessed over HTTP. Nonetheless, many major websites continue to serve content In practice, this approach is prone to flaws that can expose over unencrypted connections, which exposes the users’ HTTP sensitive information or functionality to third parties. In this paper, we conduct an in-depth assessment of a diverse cookies to attackers monitoring their traffic. Not enforcing set of major websites and explore what functionality and infor- ubiquitous encrypted connections may be attributed to various mation is exposed to attackers that have hijacked a user’s HTTP reasons, ranging from potential increases to infrastructure costs cookies. We identify a recurring pattern across websites with and the loss of in-network functionality [2] to maintaining partially deployed HTTPS; service personalization inadvertently support for legacy clients. If access control policies correctly results in the exposure of private information. The separation of functionality across multiple cookies with different scopes separated privileges of authenticated (e.g., session cookies) and inter-dependencies further complicates matters, as imprecise and non-authenticated cookies (e.g., persistent tracking cook- access control renders restricted account functionality accessible ies), stolen HTTP cookies would not allow attackers to obtain to non-session cookies. Our cookie hijacking study reveals a any personal user information. However, that is not the case number of severe flaws; attackers can obtain the user’s home in practice [3], and things become worse as services continue and work address and visited websites from Google, Bing and Baidu expose the user’s complete search history, and Yahoo to sacrifice security over usability. Websites assign privileges allows attackers to extract the contact list and send emails from to HTTP cookies to personalize functionality, as it improves the user’s account. Furthermore, e-commerce vendors such as user experience, but avoid requesting re-authentication unless Amazon and Ebay expose the user’s purchase history (partial absolutely necessary, as it impacts user engagement. While and full respectively), and almost every website exposes the session hijacking has been extensively explored, limited at- user’s name and email address. Ad networks like Doubleclick can also reveal pages the user has visited. To fully evaluate the tention has been given to the privacy risks of non-session practicality and extent of cookie hijacking, we explore multiple cookies being hijacked; Castelluccia et al. [4] demonstrated aspects of the online ecosystem, including mobile apps, browser how stolen HTTP cookies could allow attackers to reconstruct security mechanisms, extensions and search bars. To estimate a user’s Google search history. the extent of the threat, we run IRB-approved measurements A subset of the problem we explore has been highlighted in on a subset of our university’s public wireless network for 30 days, and detect over 282K accounts exposing the cookies studies that measured the exposure of personal or personally required for our hijacking attacks. We also explore how users identifiable information (PII) in unencrypted traffic [5]–[8]. can protect themselves and find that, while mechanisms such as However, those studies are limited by nature and do not the EFF’s HTTPS Everywhere extension can reduce the attack capture the full extent of the privacy threat that users face surface, HTTP cookies are still regularly exposed. The privacy due to unencrypted connections. First, modern websites are implications of these attacks become even more alarming when considering how they can be used to deanonymize Tor users. Our highly dynamic and information can be fetched in obfuscated measurements suggest that a significant portion of Tor users may form and constructed on the client-side at runtime. Second, currently be vulnerable to cookie hijacking. websites may only serve private information over encrypted connections, while flawed access control separation renders I. INTRODUCTION that information accessible to HTTP cookies (we demonstrate With an ever-increasing part of our everyday life revolving this with Google Maps exposing a user’s address in Google around the Internet and a large amount of personal data Search). Third, eavesdropping is limited to the user’s actions being uploaded to services, ensuring the privacy of our digital for a specific time window, and certain pieces of information communications has become a critical and pressing matter. In require specific actions to be exposed, which may not occur the past few years, there has been much discussion regarding during the monitoring period. Fourth, we find that stolen HTTP cookies can also access account functionality, both explicitly Overall, our goal is twofold. First, to alert developers (e.g., send an email from the user’s account) and implicitly of the pitfalls of partially enforcing HTTPS while offering (e.g., receive personalized query results from a search engine). personalized functionality. Second, to inform users about the In this paper, we explore the extent and severity of the un- protection offered by popular security and privacy-enhancing safe practice followed by major services of partially adopting systems and the caveats of not knowing the precise extent of encrypted connections, and its ramifications for user privacy. their protection. The main contributions of this paper are: We demonstrate how HTTP cookie hijacking attacks not only • We conduct an in-depth study on the impact and gravity enable access to private and sensitive user information, but can of HTTP cookie hijacking attacks against major services. also circumvent authentication requirements and gain access Our findings demonstrate that a wide range of private to protected account functionality. To our knowledge, this information and protected account functionality is acces- is the first in-depth study exploring the privacy implications sible. The diversity of these websites suggests that this is of partial adoption of HTTPS. We audit 25 major services, a widespread systemic risk of unencrypted connections, selected from a variety of categories that include search and not a topical threat against a specific class of sites. engines and e-commerce sites. In each case, we analyze the • Our measurement study demonstrates the extent of the use of HTTP cookies, the combination of cookies required to risk; we monitor part of our university’s public wireless expose different types of information and functionality, and network over the course of one month, and identify search for inconsistencies in how cookies are evaluated. This over 282K user accounts that exposed the HTTP cookies allows us to obtain a comprehensive understanding of the required for the hijacking attacks. feasibility and impact of this class of attacks in practice. We • Our analysis on the collateral exposure of cookies shows uncover flaws in major websites that allow attackers to obtain that browser extensions, search bars, and mobile apps of a plethora of sensitive user information and also to access major vendors expose millions of users to risk. protected account functionality. As a precautionary measure, • We explore how HSTS can impact HTTP cookie hi- we conduct all experiments on our personal or test accounts. jacking. We demonstrate that partial deployment renders We conduct an IRB-approved measurement study on a sub- the mechanism ineffective, as a single unencrypted con- set of our university’s public wireless network, to understand nection may be sufficient for an attacker to obtain the the browsing behavior of users when connected to unprotected required cookies. public networks. On average, we detect more than 8K unique • We describe how major websites can be used as accounts exposing their cookies for hijacking each day. Our deanonymization vectors against users that rely on the Tor measurements have the sole purpose of estimating the number bundle for anonymity, and find that existing mechanisms of users that are susceptible to hijacking attacks; we do not cannot adequately protect users. access any user accounts, collect any personal information, • We disclosed our findings to the services we audited or attempt to deanonymize any users. and the Tor community, in an effort to assist them in Furthermore, we look at multiple practical aspects of cookie protecting their users from this significant privacy threat.
Recommended publications
  • Release 2.2.1 Kenneth Reitz
    Requests Documentation Release 2.2.1 Kenneth Reitz January 15, 2016 Contents 1 Testimonials 3 2 Feature Support 5 3 User Guide 7 3.1 Introduction...............................................7 3.2 Installation................................................8 3.3 Quickstart................................................9 3.4 Advanced Usage............................................. 15 3.5 Authentication.............................................. 25 4 Community Guide 29 4.1 Frequently Asked Questions....................................... 29 4.2 Integrations................................................ 30 4.3 Articles & Talks............................................. 30 4.4 Support.................................................. 30 4.5 Community Updates........................................... 31 4.6 Software Updates............................................. 31 5 API Documentation 49 5.1 Developer Interface........................................... 49 6 Contributor Guide 69 6.1 Development Philosophy......................................... 69 6.2 How to Help............................................... 70 6.3 Authors.................................................. 71 Python Module Index 77 i ii Requests Documentation, Release 2.2.1 Release v2.2.1. (Installation) Requests is an Apache2 Licensed HTTP library, written in Python, for human beings. Python’s standard urllib2 module provides most of the HTTP capabilities you need, but the API is thoroughly broken. It was built for a different time — and a different web.
    [Show full text]
  • The Web Never Forgets: Persistent Tracking Mechanisms in the Wild
    The Web Never Forgets: Persistent Tracking Mechanisms in the Wild Gunes Acar1, Christian Eubank2, Steven Englehardt2, Marc Juarez1 Arvind Narayanan2, Claudia Diaz1 1KU Leuven, ESAT/COSIC and iMinds, Leuven, Belgium {name.surname}@esat.kuleuven.be 2Princeton University {cge,ste,arvindn}@cs.princeton.edu ABSTRACT 1. INTRODUCTION We present the first large-scale studies of three advanced web tracking mechanisms — canvas fingerprinting, evercookies A 1999 New York Times article called cookies compre­ and use of “cookie syncing” in conjunction with evercookies. hensive privacy invaders and described them as “surveillance Canvas fingerprinting, a recently developed form of browser files that many marketers implant in the personal computers fingerprinting, has not previously been reported in the wild; of people.” Ten years later, the stealth and sophistication of our results show that over 5% of the top 100,000 websites tracking techniques had advanced to the point that Edward employ it. We then present the first automated study of Felten wrote “If You’re Going to Track Me, Please Use Cook­ evercookies and respawning and the discovery of a new ev­ ies” [18]. Indeed, online tracking has often been described ercookie vector, IndexedDB. Turning to cookie syncing, we as an “arms race” [47], and in this work we study the latest present novel techniques for detection and analysing ID flows advances in that race. and we quantify the amplification of privacy-intrusive track­ The tracking mechanisms we study are advanced in that ing practices due to cookie syncing. they are hard to control, hard to detect and resilient Our evaluation of the defensive techniques used by to blocking or removing.
    [Show full text]
  • Browser Security Information
    Browser Security Information Customer security is important to us. Our top priority is to protect the privacy of your personal account information and your financial transactions FirstLine Mortgages is leading the way in Internet banking services and uses several layers of robust security technology to help ensure the confidentiality of transactions across the Internet. The first security level begins with your Web browser. When you access FirstLine Mortgages Internet Site , your browser is checked to ensure that it meets our minimum requirements. Additionally, we only allow customers with browsers that use 128-bit encryption (one of the highest levels of browser security available today) to bank on our web site. But, even with this validation, there are other precautions you should follow to maximize your protection. You have a responsibility to ensure your own security. The browser validation will verify the browser type you are using, your browser encryption level, the version of Netscape or Microsoft browser, as well as Javascript and cookies being enabled. To access -FirstLine Mortgages Internet site , you need to use: • a Netscape browser version 4.06 or better with a minimum 128-bit encryption technology • a Microsoft browser version 4.01 SP2 or better with a minimum 128-bit encryption technology • Javascript (please see below for more information about how to check and enable Javascript support) • Cookies (see below) If your browser does not meet all of these requirements, you will need to upgrade your browser to access the FirstLine Internet Site . To upgrade your browser, select the Netscape or Microsoft button below and download the latest browser version.
    [Show full text]
  • Webproxy, DNS Hijacking, Layer Seven Level Security Approach: to Protect SAAS from Web Based DDOS and Web Service Based DDOS Attacks in Cloud
    International Journal of Engineering Research & Technology (IJERT) ISSN: 2278-0181 Vol. 2 Issue 2, February- 2013 Webproxy, DNS Hijacking, Layer Seven Level Security Approach: To Protect SAAS From Web based DDOS and Web Service Based DDOS Attacks In Cloud S.Tamilselvi1, Dr.S.Tamilarasi2,S.Loganathan3 1. M. tech , ISCF, Dr.mgr educational and research institute, chennai 2. Associate Professor, CSE, Dr.mgr educational and research institute, chennai 3.Assistant Professor, ECE, Paavai Engineering College , Namakkal, Tamil Nadu ABSTRACT Cloud services offers platform services, software services, infrastructure services via web services. Cloud computing is an emerging trend in business these type of services increases vulnerability which world. Provide services to its customers on demand, invite attackers. common vulnerabilities are services like Infrastructure services , Platform services , Software services , Network services so Security level attacks: on. Resources are maintained in the virtualIJERT IJERT datacenters for both private and public clouds. Saas 1. Dictionary attacks contains web application services, windows 2. Brute force attacks application services, tools services, console 3. Spoofing application services, third party software services so 4. Credential theft on. In web application services web based distributed 5. Password cracking denial and web services based distributed denial of attack is easily implemented hacker because web Management level attacks: application transmitted through hypertext transfer protocol and web services through XML, WSDL .In 1. Credential theft 2. Elevation of privileges this paper we introduce DNS hijacking security, Web 3. luring proxy implementation, application level security to resolve web based and web services based distributed Infrastructure layer security attacks: denial of service attacks. 1.
    [Show full text]
  • Designing Secure Systems That People Can
    15- SSL, PKIs, and Secure Communication Engineering & Public Policy Lorrie Cranor, Blase Ur, and Rich Shay March 3, 2015 05-436 / 05-836 / 08-534 / 08-734 Usable Privacy and Security 1 Today! • An introduction to SSL/TLS • An introduction to PKIs • Recent developments in this area • Usability issues • An activity to make it better 2 Overview • Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS) enable secure communication • Frequently encountered with web browsing (HTTPS) and more behind the scenes in app, VOIP, etc. 3 What we want to defend against • People snooping on our communications – The contents of what we’re sending – Session tokens (see, e.g., Firesheep) • Man-in-the-middle attacks – We want to authenticate that we are talking to the right site, not an imposter – Use certificates inside a public-key infrastructure 4 How we could obtain trust • Web of trust – People you already trust introduce you to people they trust – Can get complicated, doesn’t scale well – Less frequently seen in practice • Public-Key Infrastructure (PKI) – Certificates are issued by certificate authorities that bind cryptographic keys to identities 5 Public-Key Infrastucture • Binding of keys to identities can be done automatically or by humans 6 What does SSL look like to users? • Compare, e.g., the following: – https://www.google.com (normal certificate) – Go to Google images and then click on an image and see what happens (mixed content) – https://otalliance.org (EV certificate) 7 What does PKI look like to browsers? • Hundreds
    [Show full text]
  • But Were Afraid to Ask!)
    05_576593 ch01.qxd 10/12/04 9:55 PM Page 9 Chapter 1 All You Ever Wanted to Know about JavaScript (But Were Afraid to Ask!) In This Chapter ᮣ Understanding a working definition of JavaScript ᮣ Dispelling common JavaScript misconceptions ᮣ Getting started with JavaScript tools ᮣ Finding information online aybe you’ve surfed to a Web site that incorporates really cool features, Msuch as ߜ Images that change when you move your mouse over them ߜ Slideshow animations ߜ Input forms with pop-up messages that help you fill in fields correctly ߜ Customized messages that welcome repeat visitors By using JavaScript and the book you’re reading right now you can create all these effects and many more! The Web page in Figure 1-1 shows you an example COPYRIGHTEDof the kinds of things that you canMATERIAL look forward to creating for your own site. A lot has changed since the previous edition of JavaScript For Dummies came out. Perhaps the biggest change is the evolution of DHTML, or dynamic HTML. DHTML refers to JavaScript combined with HTML and cascading style sheets, and it’s a powerful combination you can use to create even more breathtak- ingly cool Web sites than ever before. 05_576593 ch01.qxd 10/12/04 9:55 PM Page 10 10 Part I: Building Killer Web Pages for Fun and Profit Figure 1-1: JavaScript lets you add interactive features to your Web site quickly and easily. Along with this increased power comes increased complexity, unfortunately — but that’s where this new, improved, better-tasting edition of JavaScript For Dummies comes in! Even if you’re not a crackerjack programmer, you can use the techniques and sample scripts in this book to create interactive Web pages bursting with animated effects.
    [Show full text]
  • Preventing Session Hijacking Using Encrypted One-Time-Cookies
    Preventing Session Hijacking using Encrypted One-Time-Cookies Renascence Tarafder Prapty 1, Shuhana Azmin 1 Md. Shohrab Hossain 1, Husnu S. Narman2 1Department of Computer Science and Engineering, Bangladesh University of Engineering and Technology, Bangladesh 2Weisberg Division of Computer Science, Marshall University, Huntington, WV, USA Email: [email protected],[email protected], [email protected], [email protected] Abstract—Hypertext Transfer Protocol (HTTP) cookies are cryptography-based techniques to achieve cookie confidential- pieces of information shared between HTTP server and client to ity and integrity. However, each mechanism lacks in one aspect remember stateful information for the stateless HTTP protocol or another. The scheme described in [1] does not achieve or to record a user’s browsing activity. Cookies are often used in web applications to identify a user and corresponding authen- cookie confidentiality. In [3], the web server is required to ticated session. Thus, stealing a cookie can lead to hijacking an store one-time keys that lead to key management problems. authenticated user’s session. To prevent this type of attack, a In [2] and [4], a one-time key is encrypted by the web server’s cookie protection mechanism is required. In this paper, we have public key. As public key encryption is computationally expen- proposed a secure and efficient cookie protection system. We have sive, these schemes are not efficient. [5] proposes the use of used one time cookies to prevent attacker from performing cookie injection. To ensure cookie integrity and confidentiality, we have cache cookies as an alternative to cookies for authentication of encrypted sensitive information in the cookie.
    [Show full text]
  • Protecting Encrypted Cookies from Compression Side-Channel Attacks
    Protecting encrypted cookies from compression side-channel attacks Janaka Alawatugoda1, Douglas Stebila1;2, and Colin Boyd3 1 School of Electrical Engineering and Computer Science, 2 School of Mathematical Sciences 1;2 Queensland University of Technology, Brisbane, Australia [email protected],[email protected] 3 Department of Telematics, Norwegian University of Science and Technology, Trondheim, Norway [email protected] December 28, 2014 Abstract Compression is desirable for network applications as it saves bandwidth; however, when data is compressed before being encrypted, the amount of compression leaks information about the amount of redundancy in the plaintext. This side channel has led to successful CRIME and BREACH attacks on web traffic protected by the Transport Layer Security (TLS) protocol. The general guidance in light of these attacks has been to disable compression, preserving confidentiality but sacrificing bandwidth. In this paper, we examine two techniques|heuristic separation of secrets and fixed-dictionary compression|for enabling compression while protecting high-value secrets, such as cookies, from attack. We model the security offered by these techniques and report on the amount of compressibility that they can achieve. 1This is the full version of a paper published in the Proceedings of the 19th International Conference on Financial Cryptography and Data Security (FC 2015) in San Juan, Puerto Rico, USA, January 26{30, 2015, organized by the International Financial Cryptography Association in cooperation with IACR. 1 Contents 1 Introduction 3 2 Definitions 6 2.1 Encryption and compression schemes.........................6 2.2 Existing security notions................................7 2.3 New security notions..................................7 2.4 Relations and separations between security notions.................8 3 Technique 1: Separating secrets from user inputs9 3.1 The scheme.......................................9 3.2 CCI security of basic separating-secrets technique.................
    [Show full text]
  • Infoblox White Paper
    Enterprise Strategy Group | Getting to the bigger truth.™ White Paper Enterprise DNS Security By Jon Oltsik, Senior Principal Analyst March 2018 This ESG White Paper was commissioned by Infoblox and is distributed under license from ESG. © 2018 by The Enterprise Strategy Group, Inc. All Rights Reserved. White Paper: Enterprise DNS Security 2 Contents Executive Summary ................................................................................................................................................................. 3 The State of Cybersecurity in 2018 ......................................................................................................................................... 3 DNS and Cybersecurity ............................................................................................................................................................ 5 DNS for Cybersecurity Advantage ....................................................................................................................................... 5 Enterprise-Class Secure DNS ................................................................................................................................................... 6 Enter Infoblox ActiveTrust Suite (Cloud and On-premises) ................................................................................................ 7 The Bigger Truth .....................................................................................................................................................................
    [Show full text]
  • Javascript Security
    Color profile: Generic CMYK printer profile Composite Default screen Complete Reference / JavaScript: TCR / Powell & Schneider / 225357-6 / Chapter 22 Blind Folio 679 22 JavaScript Security ownloading and running programs written by unknown parties is a dangerous proposition. A program available on the Web could work as advertised, but then Dagain it could also install spyware, a backdoor into your system, or a virus, or exhibit even worse behavior such as stealing or deleting your data. The decision to take the risk of running executable programs is typically explicit; you have to download the program and assert your desire to run it by confirming a dialog box or double-clicking the program’s icon. But most people don’t think about the fact that nearly every time they load a Web page, they’re doing something very similar: inviting code—in this case, JavaScript—written by an unknown party to execute on their computer. Since it would be phenomenally annoying to have to confirm your wish to run JavaScript each time you loaded a new Web page, the browser implements a security policy designed to reduce the risk such code poses to you. A security policy is simply a set of rules governing what scripts can do, and under what circumstances. For example, it seems reasonable to expect browsers’ security policies to prohibit JavaScript included on Web pages downloaded from the Internet from having access to the files on your computer. If they didn’t, any Web page you visited could steal or destroy all of your files! In this chapter we examine the security policies browsers enforce on JavaScript embedded in Web pages.
    [Show full text]
  • Guideline for Securing Your Web Browser P a G E | 2
    CMSGu2011-02 CERT-MU SECURITY GUIDELINE 2011 - 02 Mauritian Computer Emergency Response Team Enhancing Cyber Security in Mauritius Guideline For Securing Your Web Browser National Computer Board Mauritius JuJunene 2011 2011 Version 1.7 IssueIssue No. No. 4 2 National Computer Board © Table of Contents 1.0 Introduction .......................................................................................................................... 7 1.1 Purpose and Scope ........................................................................................................... 7 1.2 Audience........................................................................................................................... 7 1.3 Document Structure.......................................................................................................... 7 2.0 Background .......................................................................................................................... 8 3.0 Types of Web Browsers ....................................................................................................... 9 3.1 Microsoft Internet Explorer .............................................................................................. 9 3.2 Mozilla Firefox ................................................................................................................. 9 3.3 Safari ................................................................................................................................ 9 3.4 Chrome ..........................................................................................................................
    [Show full text]
  • Godaddy – Domain Hijacking
    Domain Hijacking Matthew C. Stith, Spamhaus Eddy Winstead, ISC April 29th, 2020 https://www.isc.org What we’re going to covering • What why and how of domain hijacking • Examples of various hijacking methods • High profile stories about hijacked domains • What can be done to protect domains and networks • Q&A 2 What is Domain Hijacking? • Malicious actors gaining access to the DNS records of a legitimate domains (which they do not own): • In some cases only the root domain’s DNS is changed. This is reflected in the WHOIS. • In other cases a new host (subdomain) is created with new DNS settings. This practice is called domain shadowing. This is not visible at the WHOIS level. 3 Why is it exploited? These following two factors lead to a positive reputation: • The age of the domain • The legitimacy of the domain Meaning many of these domains could be able to send email or serve content without much scrutiny from content or reputation filters. 4 How is it happening? Phishing Social Compromised Exploiting Malware engineering DNS weaknesses in applications 5 Investigating domain hijacking • Passive DNS data is collected with special Client queries local DNS resolver Passive DNS Data probes activated on a DNS Resolver. Domain not included in cache • The probes record anonymized cache Data from Query external root server recursive miss. segment is recorded • Data is collected through DNS recursive Domain not found servers. Query top level domain server • Simple and extensive search functionalities make this data easy to Domain not found Client
    [Show full text]