0

Below is an excerpt from https://policies.google.com/technologies/cookies#security

The ‘pm_sess’, ‘YSC’ and ‘AEC’ cookies ensure that requests within a browsing session are made by the user, and not by other sites. These cookies prevent malicious sites from acting on behalf of a user without that user’s knowledge.

Can you please explain how (technically) the use case described by the above excerpt is implemented? For example, when a hostile JS makes an API call (1- from within a google domain webpage and 2- from other domains) to google on behalf of the logged in user, the session cookies are not sent to google along with the api call (not made by the user) in the context of the above excerpt?

1 Answer 1

0

Looking briefly at Gmail, the only one of those cookies that I see is AEC. However, it does have an interesting property: unlike the vast majority of Google's cookies, AEC has the SameSite attribute set (specifically, SameSite=lax). This will in fact prevent it from being sent from "malicious sites"... with a great deal of caveats.

SameSite is a feature of cookies, added in an update to the HTTP specification, that limits the sending of cookies across domains. Historically, cookies were included if their domain matched that of the request, regardless of where the request initiated. This led to CSRF (Cross-Site Request Forgery, sometimes called XSRF) vulnerabilities, because a malicious site could send requests (via XHR, fetch, or simply submitting an HTML form) to another site and, if you were signed into the other site, the cookies would go along with it. There are many ways to defeat CSRF - some better than others - but until SameSite, they were all workarounds for the browser's behavior. SameSite introduces a way to make the browser change its behavior: it will only send cookies flagged as such if the initiator of the request and the destination of the request are considered the same "site" (plus some additional rules around the difference between "Lax" and "Strict" modes; the former allows top-level navigation requests to send cookies no matter where they come from).

Unfortunately, SameSite is much weaker than you might think. First of all, the "Site" in question is NOT the same as the Origin; a different site is always a different origin, but the reverse is not at all true. Origin considers protocol (HTTP vs. HTTPS vs. anything else); SameSite does not. Origin considers port (by default 80 for HTTP, 443 for HTTPS, but either can be served over any port); SameSite does not. Origin considers all parts of the fully-qualified domain; SameSite does a slightly confusing thing that can be thought of as "considers only the top-level domain but not sub-domains", though the actual detail involves the Public Suffix List.

Furthermore, SameSite is not implemented universally. While all major modern browsers implement it, older or minor browsers (or older versions of major ones) might not (e.g. Internet Explorer never got support for SameSite). Furthermore, the implementation varies across browsers and versions; most browsers now treat all cookies as though they are SameSite=lax by default if they don't specify a different value, however, some browsers coughApplecough don't do this and for a while there even had a bug where specifying SameSite=none (necessary if you want the legacy cookie behavior on browsers that have the new default) would instead be interpreted as SameSite=strict). Given all that, Google almost certainly implements at least one other anti-CSRF approach in addition to setting (and presumably checking for) a cookie with the SameSite attribute set.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .