Reconless2020-06-01T17:04:46+00:00https://blog.reconless.com/Samesite by Default and What It Means for Bug Bounty Hunters2020-01-31T00:00:00+00:00https://blog.reconless.com//samesite-by-default<p>You have probably heard of the <code class="language-plaintext highlighter-rouge">SameSite</code> attribute addition to HTTP cookies since Chrome 51 (and a <a href="https://tools.ietf.org/html/draft-west-cookie-incrementalism-00">specification</a> 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.</p>
<p><img src="/assets/samesite-devtools-warnings.png" alt="A warning from Chrome's devtools regarding the upcoming changes" /></p>
<p>After the update, all cookies without an explicit <code class="language-plaintext highlighter-rouge">SameSite</code> attribute will be treated as having <code class="language-plaintext highlighter-rouge">SameSite=Lax</code>. This means cross-origin requests no longer carry cookies, except for top-level navigations.</p>
<p>While this may come as sad news to bug bounty hunters, modern webapp frameworks have already largely mitigated CSRF so this doesn’t seem <em>that</em> bad — CSRF is no longer in the OWASP Top 10.</p>
<p>This begs the question: Is CSRF the only bug class that relies on authenticated cross-origin requests?</p>
<p>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 <code class="language-plaintext highlighter-rouge">SameSite</code> by default.</p>
<h2 id="clickjacking">Clickjacking</h2>
<p>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 <code class="language-plaintext highlighter-rouge">localStorage</code> or <code class="language-plaintext highlighter-rouge">sessionStorage</code>.</p>
<h2 id="cross-site-script-inclusion">Cross-Site Script Inclusion</h2>
<p>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 <a href="https://www.chromium.org/Home/chromium-security/corb-for-developers">CORB</a> has partially addressed this type of vulnerability, but the <code class="language-plaintext highlighter-rouge">SameSite</code> update is the final nail in the coffin.</p>
<h2 id="jsonp-leaks">JSONP Leaks</h2>
<p>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 <code class="language-plaintext highlighter-rouge">SameSite</code> on cookies. Cases where an adversary exploits accidental JSONP support by middleware (adding <code class="language-plaintext highlighter-rouge">?callback=</code> to an endpoint) will be eliminated.</p>
<h2 id="data-exfiltration">Data Exfiltration</h2>
<p>This bug category abuses different techniques to bypass SOP. Examples include <a href="https://blog.innerht.ml/cross-origin-css-attacks-revisited-feat-utf-16/">CSS Exfiltration</a> and <a href="https://christian-schneider.net/ChromeSopBypassWithSvg.html">SOP bypass on browser level</a>. These examples are affected in the same way as XSSI — cross-origin requests are no longer authenticated.</p>
<h2 id="xsleaks">XSLeaks</h2>
<p>XSLeaks will be affected for the same reason as XSSI. That being said, certain side-channel techniques via <code class="language-plaintext highlighter-rouge">window.open</code> may still work since those are considered top-level navigation.</p>
<h2 id="cors-misconfigurations">CORS Misconfigurations</h2>
<p>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 <code class="language-plaintext highlighter-rouge">SameSite</code> 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 <code class="language-plaintext highlighter-rouge">SameSite=Lax</code> because it will force the request to drop the cookies.</p>
<h2 id="cross-site-websocket-hijacking">Cross-Site WebSocket Hijacking</h2>
<p>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 <code class="language-plaintext highlighter-rouge">SameSite</code> by default.</p>
<h2 id="xss">XSS</h2>
<p>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 <a href="https://blog.innerht.ml/rpo-gadgets/">RPO via Open Redirect</a> not under attackers’ control.</p>
<hr />
<p>The list is, of course, not conclusive as there are many variations based on similar techniques.</p>
<p>To recapitulate, the following table illustrates how badly affected each vulnerability type listed above is:</p>
<table>
<thead>
<tr>
<th>Vulnerability Type</th>
<th>Affected by SameSite</th>
</tr>
</thead>
<tbody>
<tr>
<td>Clickjacking</td>
<td>😦Partly Dead</td>
</tr>
<tr>
<td>XSSI</td>
<td>☠️Totally Dead</td>
</tr>
<tr>
<td>JSONP Leaks</td>
<td>😦Partly Dead</td>
</tr>
<tr>
<td>Data Exfiltration</td>
<td>☠️Totally Dead</td>
</tr>
<tr>
<td>XSLeaks</td>
<td>😵Mostly Dead</td>
</tr>
<tr>
<td>CORS Misconfigurations</td>
<td>😃Mostly Fine</td>
</tr>
<tr>
<td>Cross-Site WebSocket Hijacking</td>
<td>☠️Totally Dead</td>
</tr>
<tr>
<td>XSS</td>
<td>😃Mostly Fine</td>
</tr>
</tbody>
</table>
<h2 id="end-of-an-era">End of an Era?</h2>
<p>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 <code class="language-plaintext highlighter-rouge">SameSite</code> update has already affected <a href="https://groups.google.com/a/chromium.org/d/msg/blink-dev/AknSSyQTGYs/lXBt8xyGAgAJ">Microsoft Login</a>.</p>
<p>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. <a href="https://twitter.com/RenwaX23">@RenwaX23</a> wrote an <a href="https://medium.com/@renwa/bypass-samesite-cookies-default-to-lax-and-get-csrf-343ba09b9f2b">excellent article</a> explaining how to abuse this temporary behavior.</p>
<p>The good news is legacy applications are likely going to offset the change themselves.</p>
<blockquote class="twitter-tweet"><p lang="en" dir="ltr">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 :) <a href="https://t.co/EjLLBPvqCb">https://t.co/EjLLBPvqCb</a></p>— Artur Janc (@arturjanc) <a href="https://twitter.com/arturjanc/status/1221161819366207492?ref_src=twsrc%5Etfw">January 25, 2020</a></blockquote>
<script async="" src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<p>In addition, other modern technologies may be forced to offset the change.</p>
<blockquote class="twitter-tweet"><p lang="en" dir="ltr">SameSite=Lax cookie issues imminent for AMP-enabled websites since the AMP cache loads under a faux first party: <a href="https://t.co/MQsEhV6GLi">https://t.co/MQsEhV6GLi</a></p>— John Wilander (@johnwilander) <a href="https://twitter.com/johnwilander/status/1221920858966413312?ref_src=twsrc%5Etfw">January 27, 2020</a></blockquote>
<script async="" src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
<p>And lastly, browser support for <code class="language-plaintext highlighter-rouge">SameSite</code> by default vary as illustrated below.</p>
<table>
<thead>
<tr>
<th>Browser</th>
<th>Support</th>
</tr>
</thead>
<tbody>
<tr>
<td>Chrome</td>
<td>✅<a href="https://www.chromium.org/updates/same-site">Supported</a></td>
</tr>
<tr>
<td>Firefox</td>
<td>⏲<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1604212">In Development</a></td>
</tr>
<tr>
<td>Safari</td>
<td>❌No Signals</td>
</tr>
<tr>
<td>Edge</td>
<td>🧪<a href="https://docs.microsoft.com/en-us/microsoft-edge/web-platform/site-impacting-changes">Experimenting the change in Canary/Dev channels</a></td>
</tr>
<tr>
<td>Internet Explorer</td>
<td>❌No Signals</td>
</tr>
</tbody>
</table>
<p>For now, it is safe to say while CSRF and other client-side vulnerabilities may be affected by the <code class="language-plaintext highlighter-rouge">SameSite</code> 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.</p>