The function of a Browser Cookie is to be able to identify and remember things about you as you go along your web sessions. Logically speaking, all cookies are essentially text files that hold vital information about an established session. The World Wide Web in of itself one of the most innovating technologies to date, yet it lives on brittle foundation, littered with specifications to reinforce it.
Cookies are vital to how the WWW works. The attack exposure that cookies produce are poignant to the protections and processes required to ensure its integrity and confidentiality. To understand why, we need to take a look at a cookies life-cycle from when it is established to when it is used and disposed of. It’s also worth to note that the cookie protocol is still been based on RFC 2109 which was created 20 years ago.
Properties of a Cookie
Cookies are scoped to the domain that sent the request for a “Set-Cookie” response. So if I were to send a request from lotuseater.io with HTTP headers of Domain and Path to the backend server I would get a Set-Cookie response for *.lotuseater.io. The cookie is then resent for all the domains that match *.lotuseater.io while pages are requested.
The problem with cookies is that when setting a cookie in HTTP (Unencrypted communication) the cookie would be sent in plain-text. All it would take to steal it is for someone to be sniffing the HTTP traffic of your local network (or Coffee Shop) capture your cookie and then they would be on their way to impersonating your identity on the scoped website (in this case lotuseater.io).
Luckily more websites and browsers are enforcing HTTPS for website requests you might see requests over HTTP to throw the “Proceed with caution” page. The green lock at the top of your browser along with reputable certification authorities are what allows web security professionals to sleep soundly at night.
Some special flags than can be sent with the cookie request that enforces confidentiality (but not integrity) are the HTTPOnly and Secure Flags.
Specification can be found here.
Fun Fact: The HTTPOnly flag were first used by Microsoft in 2002 where Internet Explorer garnered 96% of the market in terms of browser usage. Remember Neopets?
Breaches that resulted in broken cookie authentication
The most notable breach that involved the use of browser cookies would be the Yahoo breach of 2013–2016 and the events that led to further exploitation. This was one of the biggest breaches that pretense Equifax, nearly billions of user records were ex-filtrated from Yahoo Servers. The data was then sold on the dark web.
It was then weaponized by APT groups (state sponsored) to spy on government officials by taking over their personal Yahoo account.
More information about the Yahoo Breach
Symbiotic relationship between Same Origin Policy and Cookies
Outside of sniffing unencrypted traffic, the Same Origin Policy is what keeps code from sending data to different origins, but as we have seen with these breaches there are many ways around such a thing. Without the almighty law of SOP the web would certainly be a much different place…
Try it out: Go to an account you logged in with Facebook, Google, Instagram what have you, open up your console (Ctrl+Shift+I) or Right-click -> Inspect
As an attacker this is the treasure they are trying to plunder when executing session or account takeovers.
Establishment of Session
The birth of a cookie starts at the cookie request. A request is usually from a DOM activity or form being sent which attaches to a cookie session. Examples include a login or adding an item to a shopping cart without logging in. Cookies will either be born as some form of a session cookie, tracking cookie or permanent cookie all have their unique traits to the types of data they collect.
A session consist of many HTTP request/response handshakes to maintain the state of a user. A session once established can either last for an exceptionally long time or rather short amount of time depending on when it expires.
Certain applications like financial applications will have a short session while applications in social media or mail can have longer sessions. This is dictated by Expires: <Date of expiration> directive set by the server in the Set-Cookie response. The browser then uses the cookie for requests within it’s scope to send information such as user activity, clicks, account data back to the server. The browser will also use the cookie to maintain the session for the user.
Cookie Jar and Idleness
The cookies that tend to have a long shelf life will sit in your cookiejar idle, waiting, most cookies nowadays will take form of a tracking cookie where the data would be used across websites to identify you as an individual and your browsing habits. The same mechanisms are used to establish a “session” as a user but many are established on multiple websites, most will have a check to see if their cookies are already established in your requests. It will then record data, update your cookie, or add another one.
Cookie End of Life
All cookies have a shelf-life, this is due to the Expired header, once it reaches the date of expiry, your browser would initiate garbage collection of expired cookies when further requests are made. Yes this is a quite sad, but the cycle of life continues, as soon as a cookie dies, many more will be born.
Thanks For Reading.