1

I am solving PortSwigger's lab: "CSRF where token is tied to non-session cookie". For testing SameSite attribute I created a cookie in my browser with SameSite=Strict for domain https://<id>.web-security-academy.net/.

enter image description here

Then on https://exploit-<id>.web-security-academy.net/exploit I hosted the exploit with the payload:

<form method="post" action="https://<id>.web-security-academy.net/my-account/change-email">
   <input type="hidden" name="email" value="hello@email.ru">
</form>

<img src="foo" onerror="document.forms[0].submit()">

I expected that my browser won't send my cookie with SameSite=Strict when I open exploit, but it adds them.

enter image description here

Can you explain why, please?

nobody
  • 11,251
  • 1
  • 41
  • 60
ZOOM SMASH
  • 113
  • 4

1 Answers1

3

In short: because samesite doesn't mean "same origin", webapps were a mistake, and cookie security is a disasterconsiders most subdomains equivalent for the specific purpose of the samesite flag.

Cookies have a peculiar and unique approach to domains. Without going into the full details here, the "site" for a cookie is substantially broader in scope than the origin of a site (which is well-defined and generally excludes the things you might expect). Pages across different ports of the same domain are considered same-site, and until recently the same was true of pages across different schemes (protocols) such that http://example.com/ could cause samesite cookies - including secure cookies unavailable to the request origin - to be sent for https://example.com/.

The real mess, though, is in subdomains (as you found). If you want to go to the canonical source, see https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-cookie-same-site-00, in particular section 2.1, and try to figure out what the heck it means (I'll save you the effort, for the part needed to answer your question, below).

There is a concept of a "site for cookies" (see 2.1.1 of the RFC), which is "either a registrable domain, or the empty string". OK, so what's a "registrable domain"? Goooood question. Is the "same registrable domain" a sound security basis for cookies? tries to get an answer to that, but the very short version is: usually it's the root zone + the top-level domain (also known as "TLD+1"). So, "registrabledoma.in" is probably a registrable domain (in India's TLD), but "unregistrable.domain.com" is probably not; the relevant registrable domain would be "domain.com".

I stress probably because it's not as simple as "no subdomains". There's a thing called the Public Suffix List, maintained by Mozilla and used by all major browsers, that documents under what suffixes people are allowed to register names. Looking at the list, we can see that "com" is a public suffix (have fun searching for it; I recommend a regular expression), so "domain.com" is a registrable domain. "domain.com" is not a public suffix, so "unregistrable.domain.com" is not a registrable domain. (Some other examples of public suffixes include "co.uk", "fr.eu.org", "environmentalconservation.museum", and "s3.dualstack.ap-northeast-2.amazonaws.com".)

Anyhow, bringing this back to your question:

"web-security-academy.net" is not a public suffix, but "net" is. As such, the registrable domain is "web-security-academy.net" for both "<id>.web-security-academy.net" and for "exploit-<id>.web-security-academy.net". Since they are also both HTTPS, they are - for cookie purposes - the same site. There's your answer.

This doesn't mean they're the same domain for cookie purposes (that would be consistent, you see), so requests to the one domain don't get cookies scoped exclusively to the other domain. Though it will get cookies scoped to a common parent, unless the domain scope is unspecified and thus implicitly "the current domain without subdomains, a property that can't be specified explicitly. Also you aren't allowed to scope cookies to a public suffix, which is very reasonable once a list of such things exists at all.

Anyhow, now you know why samesite is not considered a fully adequate mitigation for CSRF, even on conforming browsers. It's because what they conform to is insaneless restricting than you expect.

CBHacking
  • 40,303
  • 3
  • 74
  • 98