Chrome Canary Samesite
- Use one browser with multiple active sessions per site. Log into multiple accounts on the same site simultaneously. No more need for secondary browsers, private sessions, let SessionBox handle these for you.
- But, the mentioned issue is coming in 'Google Chrome Canary' and not able to access the embedded appliations. For that, I Plan to add SameSite cookie. – Suresh Kumar Dec 5 '19 at 17:18.
31 January 2020
So I tried using Chrome canary and also enabling flags #same-site-by-default-cookies and #cookies-without-same-site-must-be-secure as per the documentation.
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.
Chrome Canary Vs Edge Canary
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.
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:
| Vulnerability Type | Affected by SameSite |
|---|---|
| Clickjacking | 😦Partly Dead |
| XSSI | ☠️Totally Dead |
| JSONP Leaks | 😦Partly Dead |
| Data Exfiltration | ☠️Totally Dead |
| XSLeaks | 😵Mostly Dead |
| CORS Misconfigurations | 😃Mostly Fine |
| Cross-Site WebSocket Hijacking | ☠️Totally Dead |
| XSS | 😃Mostly Fine |
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
— Artur Janc (@arturjanc) January 25, 2020In addition, other modern technologies may be forced to offset the change.
SameSite=Lax cookie issues imminent for AMP-enabled websites since the AMP cache loads under a faux first party: https://t.co/MQsEhV6GLi
— John Wilander (@johnwilander) January 27, 2020And lastly, browser support for SameSite by default vary as illustrated below.
| Browser | Support |
|---|---|
| Chrome | ✅Supported |
| Firefox | ⏲In Development |
| Safari | ❌No Signals |
| Edge | 🧪Experimenting the change in Canary/Dev channels |
| Internet Explorer | ❌No Signals |
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.
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 the Chromium Blog.
How does this affect my application?
As apps are loaded in the BigCommerce Control Panel using an iframe, any cookies that your app uses will be considered “cross-site” cookies from Chrome’s perspective. This includes things like session cookies which may be absolutely essential for your app to function.
Chrome Canary Same Site Website
Therefore, if these cookies are not set to have a SameSite=None; Secure policy, they will not be sent from the browser at all, and your application may fail to function as intended.
What do I need to change?
Whenever you are setting cookies for your BigCommerce app, make sure that those cookies are set with an explicit SameSite=None; Secure policy.
For further reading, consider Google’s guidance on managing SameSite cookie policies for iframes.
How do I test my app after making these changes?
These changes to Chrome will launch with the release of Chrome 80 and are available in Chrome Canary now for your early testing and verification. If your app installs, loads, and functions correctly in the latest version of Chrome Canary, then you can feel confident it will work in Chrome 80.