Hack Yourself First (Module 3 — Cookies 🍪)

My fingers are absolutely freeeezing! ☃️❄️

I did a super fun workout this morning and it involved a lot of skipping outdoors, but my fingers are failing me… so typing this up is a challenge for me right now. 😅

But can you smell that? It’s the heavenly aroma of freshly baked cookies waiting for us to devour them - so here we go!

Source: https://blog.larapulse.com/web/protect-cookies

Module 3: Cookies

Cookies 101

Cookie: Delicious treats that we indulge in. Also simple pieces of text stored in the browser.

Source: Pluralsight Hack Yourself First

• The server may set a cookie via the HTTP response header or the cookie may be set/read via JavaScript directly in the DOM
• Cookies are automatically passed back to the website in the header of each request

Source: Pluralsight Hack Yourself First

• Cookie Security:
  - Cookies frequently contain sensitive data (e.g. auth cookies)
  - Browser implements native defences to protect cookies but there are limits to this as it can still be explored by attacks such as XSS
  - By modifying their attributes, we can further secure the cookies (attributes such as the domain, path, expiration, HttpOnly, Secure, etc)

Understanding HttpOnly cookies

Evidence of HttpOnly not being set for the AuthCookie — Source: Pluralsight Hack Yourself First

• If a cookie is not marked as HTTPOnly, it means that the cookie is accessible via client script → risk of a session hi-jack
• When we add the HTTPOnly flag to the AuthCookie, it helps to mitigate against an XSS risk

Observing the HttpOnly flag when inspecting the response headers — Source: Pluralsight Hack Yourself First

Understanding secure cookies

Evidence of HttpOnly and Secure attribute being set for the AuthCookie — Source: Pluralsight Hack Yourself First

• Secure attribute → ensures that the cookie is only sent via HTTPS requests

Restricting cookie access by path

The path for all cookies are set to “/” — Source: Pluralsight Hack Yourself First

• The path is set to “/“ by default → which means for every single request in any path of the website, these cookies are passed whether they’re required or not
• When the user selects remember me, the email and password cookies are also sent alongside the AuthCookie
• Side-note: it’s bad practice to have the email and password passed as cookies - we will explore that later on in the course in the “Account Management” module
• Limit the scope of the cookie, based on the path

Source: GIPHY

Reducing risk with cookie expiration

Source: GIPHY

• It’s essential for cookies to be available when users need it but it also poses a serious risk
• Whilst that cookie is active, it means that attacks such as XSS, CSRF, click-jacking etc can take place
• Usability VS Security
• Expires/ Max-Age attribute → Is there really a valid use-case for the amount of time set
• Minimise the window for potential session hi-jacking as much as possible without affecting usability too much
• Social media sites vs banking sites → How high is the end-users’ tolerance for friction when logging in?

Source: https://www.fintechfutures.com/2017/01/icici-bank-and-hdfc-bank-embrace-social-media/

Using session cookies to further reduce risk

• Another common option for cookie expiration:
  Session cookie → when the browser closes, the cookie will be gone
• Trade-off: what is someone just leaves there browser on and forget to close their session?
• Important to consider the pros and cons with setting cookie expiration

Summary:

• Cookies are relatively simple concept yet they are frequently configured in a sub-optimal way in terms of security
• HttpOnly is crucial if the cookie isn’t required to be accessed via client script
• Any cookie holding sensitive data should be marked as “secure”
• Consider the path scope of a cookie
• Try and expire cookies as quickly as possible without affect user experience too negatively