Add Flavour to Your Cookie with Enhanced Samsite Ingredient

Image for post
Image for post
Photo by Chaman Raj on Unsplash

Not long ago, my friend’s company (let’s say amazingCorp )conducted a Pen test against the whole codebase and identified a few security vulnerabilities. One of them being adding samesite attribute to all cookies if it’s absent.(e.g. mostamazingCorp.com cannot make cross-domain requests to API.amazingCorp.com) . To be more specific, he wants:

But first… what is a Cookie?

An HTTP cookie (web cookie, browser cookie) is a small piece of data that a server sends to the user’s web browser. The browser may store it and send it back with later requests to the same server.

Cookies are mainly used for below purposes:

  • Session management: E.g. Logins, shopping carts
  • Personalisation: E.g. User preferences
  • Tracking: Recording and analyzing user behavior e.g. Google Analysis

Each cookie is a key=value pair along with a number of attributes that control when and where that cookie is used. One of them that we will focus on today is the SameSite attribute.

Samsite Attribute

SameSite of the Set-Cookie HTTP response header allows you to declare if your cookie should be restricted to a first-party or same-site context. (RFC6265bis)

What count as samsite?

Well, any cookie is associated with a domain. If this domain is the same as the domain of the current application, the cookie is called a first-party cookie (samesite). If the domain is different, it is a third-party cookie.

In real world, an application will contain some 1st party cookie as well as a some 3rd parties for advertising and tracking purpose, e.g. Segment for Tracking, and Google for ads.

But beware that about the public domain suffix list. A “public suffix” is one under which Internet users can directly register names. Some examples of public suffixes are .com, .co.uk.

So login.amazingCorp.com are of the samesite as www.amazingCorp.com . But io is not a public domain suffix so login.amazingCorp.io cannot make request to www.amazingCorp.io .

Samesite Ingredients

The SameSite attribute can be set as below values:

  • Lax: The cookie is not sent on cross-site requests, but is sent when a user is navigating to the origin site from an external site (e.g. if following a link). It is helpful when e.g. a referral link is used, you want to record the site from which the user navigate from and their preferences. This is the default if the SameSite attribute is not specified.
  • Strict: The browser only allow cookie for same-site requests. This is good with cookies relating to password change or payment request.
  • None: The browser sends the cookie with both cross-site and same-site requests. This is helpful if your application can be consumed as embedded content then you should use None to indicate your intent. Note that the Secure attribute must also be set .Secure only sent to the server when a request is made with the https: scheme (except on localhost), and therefore is more resistent to man-in-the-middle attacks. Set-Cookie: example="example"; SameSite=None; Secure

Note that for Lax, the situations in which cookies can be sent cross-site must satisfy both of the following:

  • The request must be a top-level navigation. Think of this when the URL shown in the URL bar changes.
  • The request method must be safe e.g. GET or HEAD, but not POST.

For example if we are on amazingCorp.com and there is an iframe in which notAmazingCorp.com is loaded. There’s no top-level navigation. Therefore neither Lax nor Strict cookies are sent tonotAmazingCorp.com . Or if we POSTs a form to notAmazingCorp.com. Since the method is unsafe, so neither Lax nor Strict cookies are sent.

You can also use Domain and Path attributes to restrict the scope of the cookie.

  • Domain attribute:

The Domain attribute specifies which hosts are allowed to receive the cookie. It defaults to the same host that set the cookie, excluding subdomains. If Domain is specified, then subdomains are included. Thus, specifying Domain is less restrictive than omitting it. Here’s a checklist if a cookie’s domain attribute is set:

  • the cookie is applicable to that domain and all its subdomains;
  • the cookie’s domain must be the same as, or a parent of, the origin domain
  • the cookie’s domain must not be a top level domain, a public suffix, or a parent of a public suffix.

As an examplex.y.z.com can set a cookie domain to itself or parents - x.y.z.com, y.z.com, z.com. But not com, which is a public suffix; a cookie with domain=y.z.com is applicable to y.z.com, x.y.z.com

  • Path attribute

The Path attribute indicates a URL path that must exist in the requested URL in order to send the Cookie header. The %x2F ("/") character is considered a directory separator, and subdirectories match as well.

For example, if Path=/docs is set, these paths match:

  • /docs
  • /docs/Web/
  • /docs/Web/HTTP

Bake your Cookie

The final step is to bake our coolie with the new ingredient. Since the application is a react framework, we are using a simple, lightweight JavaScript API for handling cookies, js-cookie

To test it:

And when we use it in the application when we need to set the cookie:

That’s pretty much it!

Happy Reading!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store