Bypass SameSite Cookies Default to Lax and get CSRF Renwa Follow Jan 8 · 5 min read

SameSite cookies, source:web.dev

SameSite Cookies the new cookie attribute that everyone is talking about, it can be used to prevent SOP bypasses and CSRF attacks. but first let's look what is it actually.

SameSite is a cookie attribute which you can tell the browser to when it should send the specific cookie in a cross origin request, it has 3 types:

SameSite None Will be sent in all cross origin requests it will be treated as normal (old) cookies

SameSite Lax Will be sent only in GET request in top window navigations such as <a> tag, window.open()..

SameSite Strict Will be sent only when the user types the website in the URL bar and presses enter

Learn more: https://web.dev/samesite-cookies-explained/

As from now Chrome 79 default cookies without SameSite will be treated as None cookies but this gonna change soon, From Chrome 80 which comes in February 4.

Cookies without SameSite attribute will be treated as Lax, that means cookies will be sent only in top window navigations and only GET requests. This might

be a good move to solve many POST CSRF attacks.

But there is something about those cookies they have a special feature called LAX+POST, from Chrome:

Chrome will make an exception for cookies set without a SameSite attribute less than 2 minutes ago. Such cookies will also be sent with non-idempotent (e.g. POST) top-level cross-site requests despite normal SameSite=Lax cookies requiring top-level cross-site requests to have a safe (e.g. GET) HTTP method.

That means if a cookie is been set or changed within 2 minutes the browser will sent the cookie in a POST request and it will be treated as None (only top window navigations) but after the 2 minutes it will become normal as Lax.

Lax+POST

This has been used to not break the web and login flows but also bring us a new attack surface, it allow us to bypass SameSite Lax by default and get a CSRF. According to the policy if a cookie is not older than 2 minutes it will be sent, How this gonna be abused in real world applications?

1.Some websites might change the session cookie from time to time then all we need is to open a new window pointing to the website, user’s session will be replaced by a newer one then we can have a CSRF attack.

2.Cookie sessions will expire after some period and the user needs to get a new session:

The attacker will open a new window pointing to the login page

Victim will login to the site and will get a new session

Attacker then can perform CSRF attacks because the cookie is just been set (not older than 2 minutes)

3.Most applications use GET request for logout function and in a top window GET request cookies with Lax will be sent that means we will have a logout CSRF that will make the cookie removed or changed.

Attacker will open a new window pointing to the logout page

Victim opens the logout page and his cookies will be changed or removed

Attacker will open a new window pointing to the login page and the user logs in

Attacker can perform CSRF attacks

4.Getting the user to login again to a website is something not efficient and require a lot of interactions, but we have a saviour (Oauth), most of the websites today have 2nd way option login which uses other providers, so if we have Logout CSRF and Oauth login then we can bypass SameSite Lax by default with less interaction.

Attacker will open a new window pointing to the logout page

Victim open the logout page and his sessions will be removed

Attacker opens a new window pointing to the Oauth login page (example.com/login/oauth/facebook)

Victim will auto re-login to the application and a new session will be set

Attacker can perform CSRF attacks because the cookie is not older than 2 minutes

5.Some applications might have an option to get a new session for some reasons, then we need somehow get the victim to click that (New Session) button or if the website uses some REST api we can just open a new window pointing to (example.com/user/new_session) then get CSRF

LAX+POST (2 minute) is a temporary thing and will be removed in future depending on when developers change their login session flows to SameSite None Secure, or use another method for cross origin requests, another case is lowering the time to 10 seconds (This will still make it possible to abuse)