Chrome Canary Samesite

31 January 2020

• Chrome Canary Vs Beta
• Chrome Canary Offline Installer

Chrome Canary Review. Beginning in February, the way Google Chrome handles cross-site cookies is changing to prevent cookies without an explicit SameSite policy from loading in cross-origin requests. More details on Chrome's upcoming changes are available on. 'Non-stable Chrome channels (e.g. Dev, Canary, and Beta) will continue with 50% enablement in Chrome 80 and later,' the Chromium project clarified at its SameSite Updates page.

1. Live on the Bleeding Edge: Use Canary. If you really want to see what Google is cooking, the Canary channel is the way to go. This is an enhanced developer build of Chrome that gets nightly commits pushed into its code—this means it's highly unstable, but is also running the absolute latest features Google is working on.
2. Mar 17, 2021 Chrome used to have a bug in this behavior, where the top-level requirement wasn't followed exactly. (It used to be that Chrome would send Lax cookies if the iframe and all of its ancestors matched the top level. This was buggy because the spec says it literally needs to be the top level.) What you're seeing is the correct behavior after the.
3. Here at Splitmango, we've been using Chrome Canary to check our cookies. Simply download Canary to your computer, making sure that it is version 80 or higher, and turn on these flags to ensure the test cookies will be blocked: In chrome://flags/ SameSite by default cookies; Enable removing SameSite=None cookies; Cookies without SameSite must.

You have probably heard of the SameSite attribute addition to HTTP cookies since Chrome 51 (and a specification thereafter). It was advertised as a CSRF killer. This attribute is going to be set by default for all cookies in Chrome 80 (February 4, 2020). We will explore what it truly means and if it really kills CSRF.

After the update, all cookies without an explicit SameSite attribute will be treated as having SameSite=Lax. This means cross-origin requests no longer carry cookies, except for top-level navigations.

While this may come as sad news to bug bounty hunters, modern webapp frameworks have already largely mitigated CSRF so this doesn't seem that bad — CSRF is no longer in the OWASP Top 10.

This begs the question: Is CSRF the only bug class that relies on authenticated cross-origin requests?

It turns out, there are a few other client-side vulnerabilities that require cookies to be present in cross-origin requests. A lot of online articles highlight the effects on CSRF but fail to mention the other impacted vulnerabilities. Below are a few bug classes that will be affected by the introduction of SameSite by default.

Clickjacking

To make Clickjacking work, the victim needs to be authenticated in an iframe embedded in the attacker's page. Since the iframe is making a cross-origin request, by dropping cookies, the victim will not be authenticated, and hence the attack will fail. Clickjacking is still a threat for Single Page Applications (SPAs) that store session ID/access tokens in localStorage or sessionStorage.

Cross-Site Script Inclusion

To exploit XSSI, an attacker embeds an authenticated cross-origin subresource that contains sensitive data of the victim. The response may not be a JavaScript file but browsers still try to parse it for compatibility reasons. Again this involves issuing a cross-origin request to fetch an authenticated subresource so this attack will not work. It is worth noting that CORB has partially addressed this type of vulnerability, but the SameSite update is the final nail in the coffin.

JSONP Leaks

Although they are a subset of XSSI, JSONP leaks may still work in specific scenarios. This is because JSONP is intended to be used cross-origin, and hence site owners will undo SameSite on cookies. Cases where an adversary exploits accidental JSONP support by middleware (adding ?callback= to an endpoint) will be eliminated.

Data Exfiltration

This bug category abuses different techniques to bypass SOP. Examples include CSS Exfiltration and SOP bypass on browser level. These examples are affected in the same way as XSSI — cross-origin requests are no longer authenticated.

XSLeaks

XSLeaks will be affected for the same reason as XSSI. That being said, certain side-channel techniques via window.open may still work since those are considered top-level navigation.

CORS Misconfigurations

CORS misconfigurations may be the least affected vulnerability class mentioned here because CORS is meant to be used cross-origin, as the name suggests. When developers intentionally enable CORS they will be circumventing the SameSite attribute and allowing authenticated cross-origin requests. Keep in mind though, even when intentionally enabled, most exploitable cases consist of a white-list bypass as we have seen in the past. Attacks that rely on sites that have accidentally enabled CORS are most likely going to be affected by SameSite=Lax because it will force the request to drop the cookies.

Cross-Site WebSocket Hijacking

Much like CSRF, CSWSH is where a page can establish a cross-origin connection but via a WebSocket. This bug class will be impacted by the introduction of SameSite by default.

XSS

XSS is affected when an exploit chain involves a cross-origin response. For instance, when attempting to bypass a CSP via an authenticated JSONP endpoint or RPO via Open Redirect not under attackers' control.

Cinemagraph pro 2 2 0 download free. The list is, of course, not conclusive as there are many variations based on similar techniques.

To recapitulate, the following table illustrates how badly affected each vulnerability type listed above is:

Cross-Site Script Inclusion

To exploit XSSI, an attacker embeds an authenticated cross-origin subresource that contains sensitive data of the victim. The response may not be a JavaScript file but browsers still try to parse it for compatibility reasons. Again this involves issuing a cross-origin request to fetch an authenticated subresource so this attack will not work. It is worth noting that CORB has partially addressed this type of vulnerability, but the SameSite update is the final nail in the coffin.

JSONP Leaks

Although they are a subset of XSSI, JSONP leaks may still work in specific scenarios. This is because JSONP is intended to be used cross-origin, and hence site owners will undo SameSite on cookies. Cases where an adversary exploits accidental JSONP support by middleware (adding ?callback= to an endpoint) will be eliminated.

Data Exfiltration

This bug category abuses different techniques to bypass SOP. Examples include CSS Exfiltration and SOP bypass on browser level. These examples are affected in the same way as XSSI — cross-origin requests are no longer authenticated.

XSLeaks

XSLeaks will be affected for the same reason as XSSI. That being said, certain side-channel techniques via window.open may still work since those are considered top-level navigation.

CORS Misconfigurations

CORS misconfigurations may be the least affected vulnerability class mentioned here because CORS is meant to be used cross-origin, as the name suggests. When developers intentionally enable CORS they will be circumventing the SameSite attribute and allowing authenticated cross-origin requests. Keep in mind though, even when intentionally enabled, most exploitable cases consist of a white-list bypass as we have seen in the past. Attacks that rely on sites that have accidentally enabled CORS are most likely going to be affected by SameSite=Lax because it will force the request to drop the cookies.

Cross-Site WebSocket Hijacking

Much like CSRF, CSWSH is where a page can establish a cross-origin connection but via a WebSocket. This bug class will be impacted by the introduction of SameSite by default.

XSS

XSS is affected when an exploit chain involves a cross-origin response. For instance, when attempting to bypass a CSP via an authenticated JSONP endpoint or RPO via Open Redirect not under attackers' control.

Cinemagraph pro 2 2 0 download free. The list is, of course, not conclusive as there are many variations based on similar techniques.

To recapitulate, the following table illustrates how badly affected each vulnerability type listed above is:

End of an Era?

The 'Interwebz' has been working on the assumption that cookies are sent in cross-origin requests by default, so this change is likely going to break a lot of functionality. In fact, the SameSite update has already affected Microsoft Login.

Chrome monkey-patched it by allowing cookies to be sent on top-level cross-site POST requests if they are at most 2 minutes old. @RenwaX23 wrote an excellent article explaining how to abuse this temporary behavior.

The good news is legacy applications are likely going to offset the change themselves.

As much as I'd like to retire, I'd guess that once the dust settles a large number of the applications worth attacking will set `SameSite=none`, so don't write off CSRF / XS-Leaks just yet :) https://t.co/EjLLBPvqCb

In addition, other modern technologies may be forced to offset the change. Quicksilver 1 0 – application launcher and much more.

Chrome Canary Vs Beta

SameSite=Lax cookie issues imminent for AMP-enabled websites since the AMP cache loads under a faux first party: https://t.co/MQsEhV6GLi

And lastly, browser support for SameSite by default vary as illustrated below.

Chrome Canary Offline Installer

For now, it is safe to say while CSRF and other client-side vulnerabilities may be affected by the SameSite feature, they are not completely dead, because it may be a while before sites are fully prepared for the change. Bug bounty hunters may still enjoy the last bit of this Internet antiquity until the time comes.