Wandering Thoughts archives

Strict SameSite web cookie policies probably don't do much for us

I recently read The great SameSite confusion (via). To summarize badly, this article is about how it's easy to misunderstand exactly what the SameSite cookie attribute does due to a distinction that web security draws between the ideas of 'origin' and 'site'. The simple version of the difference is that 'origin' means the exact website (the same scheme, host, and port), while 'site' simply means the domain name (which is determined based on the public suffix list). For a lot of organizations this distinction may be relatively small. However, here at the University of Toronto, the distinction is very big. As a consequence, the effects of a strong SameSite policy (whether set explicitly or through browser defaults) is relatively modest for our websites.

The University of Toronto mostly uses the domain 'utoronto.ca'. However, we have a great many organizational units (faculties, departments, groups, and so on), and these mostly have websites with names that are either direct sub-names of utoronto.ca (such as 'utcc.utoronto.ca') or names in subdomains, such as 'www.utsc.utoronto.ca'. All of these are very different websites, run by very different groups with very different security policies and so on, but they're all the same 'site' as far as SameSite is concerned. As a result, even the strictest SameSite policy won't prevent cookies from leaking from one of these websites to another.

Fortunately, all is not lost for our (potential) desire to keep from leaking cookies between our different websites. Cookies have always had a basic limitation on what hosts they're sent to, as covered in the relevant MDN section. If someone with a website here sends a cookie without a Domain attribute, it won't leak outside of them and their sub-domains. To leak a cookie to all University of Toronto websites, you would have to explicitly set 'Domain=utoronto.ca'. Well, you or the framework you're using would have to do that, since people often don't manually set cookies. Hopefully there aren't many frameworks that default their cookie domains to the 'site' (as the web defines it).

(One corollary of this is that there is a lot of scope for 'same-site' requests in general on University of Toronto websites, for both good and, unfortunately, evil. If an attacker wants to find a place to put some content that will be same-site for an important UofT website, they're probably not going to have much trouble. There are even various subdomain names that look very similar to each other.)