Protections against cross-site request forgery could be bypassed

Chromium bug allowed SameSite cookie bypass on Android devices

A recently patched bug in the Chromium project could allow malicious actors to bypass a security feature that protects sensitive cookies on Android browsers.

The SameSite setting enables developers to restrict access to cookies. For example, by setting SameSite=strict, this can prevent a cookie from showing up in HTTP responses if the user navigates to the website through a link or a redirect request from another website.

SameSite bypass with intent requests

Security researcher Axel Chong, however, discovered that he could bypass SameSite protection if he used the intent scheme to navigate to the target website. Intents are external protocol handlers that allow Android apps to open other apps, such as jumping from the browser to the Maps application or from an SMS to the browser.

“I came across this bug when I read this interesting bug on intents,” Chong told The Daily Swig. “As intent URLs could point to the same app (Chrome in this case) and create a fresh browsing context, I had then wondered what kind of security measures that intent URLs could possibly bypass.”

Intent URLs should be considered external sources and be subject to SameSite restrictions. But a proof-of-concept Chong created in Python shows that cookies with SameSite=strict settings carry over when the web server initiates a redirection with an intent URL.


Want the latest web security news straight to your inbox? Sign up to our newsletter here


The same scheme also bypasses the Sec-Fetch-Site header, which determines where the request originated from and enables websites to control access to their resources from external origins.

“Both are usually used to protect against CSRF (cross-site request forgery), so the impact would be bypassing these protections,” Chong said.

Normal redirects also affected

Further investigation showed that SameSite cookies are also carried over through simple redirect requests without the intent protocol.

While this was fixed in an earlier version of Chrome, it was later disabled because it caused breaking changes.

The experimental cookie feature flag (chrome://flags/#enable-experimental-cookie-features) would restore the secure behavior and prevent SameSite cookies from being sent across normal redirect requests.

This flag did not affect the insecure behavior of intent redirects. Chong also said that the flag did not affect the Sec-Fetch-Site behavior and needed to be fixed separately.

No easy fix

Fixing the bug was not trivial because the developers had to account for how to determine trusted applications, including browsers.

It was finally decided not to trust intents because “(a) other apps on the device may not be trustworthy, and (b) websites can use Intent URLs/redirects to reflect back to Chrome and potentially use it to bypass SameSite restrictions.”

The lesson here is that given the complicated ways apps and browsers can communicate, developers should use multiple layers of security for their applications.

“These sort of browser security mechanisms (i.e., SameSite cookies, Fetch metadata) are meant to be defense-in-depth only. You should use them but do not rely on them as the only form of defense,” Chong advised.


DON’T MISS Deserialized web security roundup: Twitter 2FA backlash, GoDaddy suffers years-long attack campaign, and XSS Hunter adds e2e encryption