SameSite Cookie Attacks

And what subdomain takeovers mean for your SameSite cookies

Photo by Pawel Czerwinski on Unsplash

I published an article a while ago about how Chrome is making SameSite the default behavior for cookies to prevent Cross-Site Request Forgery (CSRF) attacks. After that, jub0bs reached out to me about how the nuances of SameSite can leave websites vulnerable. Thanks for bringing this issue to my attention!

In this article, I discuss why we may be led to believe that SameSite cookies are more secure than they actually are, and clarify some mistakes I made in my previous article.

This article is based on jub0bs’s research on the topic. For his in-depth discussion about the topic, go here: https://jub0bs.com/posts/2021-01-29-great-samesite-confusion/.

Chrome’s SameSite Updates

CSRF vulnerabilities happen when attackers can initiate forged state-changing requests from a foreign domain. CSRFs are prevented by implementing CSRF tokens to ensure the authenticity of requests, or by using SameSite cookies.

About two years ago, Chrome started to set the SameSite cookie attribute to Lax by default. This setting tells the client’s browser to send a cookie only during same-site requests and requests that cause top-level navigation.

Set-Cookie: PHPSESSID=UEhQU0VTU0lE; SameSite=Lax

This default setting helps prevent CSRF attacks. Since sensitive cookies won’t be sent during cross-site requests, attackers cannot initiate authenticated requests from their sites. Several other browsers followed Chrome’s example later by making SameSite=Lax the default.

However, what exactly is a same-site request? My first intuition says that same-site requests are same-origin requests, which means that two pages have the same protocol, hostname, and port number. This is a false assumption that has important security consequences.

SameSite != SameOrigin

Notice that the cookie attribute is named SameSite and not SameOrigin.

The definition of a “Site” in this context is the registrable domain, plus the URL scheme. A registrable domain is defined as the most specific public suffix, plus the part of the domain just before the public suffix.

You can see that Origin is a much stricter classification than Site. Therefore, it’s possible for a request to be same-site, but cross-origin.

You can find a more in-depth discussion of SameSite cookies in this article: https://web.dev/samesite-cookies-explained/.

Cross-origin, Same-site Requests

Let’s take a look at why cross-origin, same-site requests are possible. First, take a look at these two URLs:

https://foo.example.com
https://bar.example.com 

Since example.com is not a public suffix, the public suffix used to define the Site of these origins is .com. The Site is defined as “public suffix plus the part of the domain just before the public suffix”, so the Site for both of these domains is example.com. Requests between these pages are cross-origin, but same-site.

On the other hand, github.io counts as a public suffix.

https://foo.github.io
https://bar.github.io

These two origins are different Sites because github.io is a public suffix. The “public suffix plus one” becomes foo.github.io and bar.github.io. Requests between these origins are cross-origin and cross-site.

Also, notice that all of these requests are HTTPS. Requests are only same-site when the URL scheme is identical.

SameSite Cookie Limitations

This subtle difference has security implications. SameSite cookies will only protect against CSRF from malicious cross-site requests, not same-site, cross-origin requests.

For example, let’s say you set your cookies for foo.example.com to SameSite=Lax. If an attacker finds a subdomain takeover at bar.example.com, they can send authenticated requests from bar.example.com.

foo.example.com and bar.example.com are same-site, since they both belong to the Site example.com. XSS vulnerabilities on a subdomain can allow attackers to launch similar attacks that bypass SameSite restrictions.

Side note: The SameSite cookie attribute determines which pages can initiate requests with those cookies. Whereas the Domain attribute restricts the hosts cookies can be sent to.

Want to Connect?
What other security concepts do you want to learn about? I’d love to know. Feel free to connect on Twitter @vickieli7.