Suggestion: New article on cross-site leaks (xsleaks)

[mozfreddyb]

https://xsleaks.dev/ has lots of content, a bit of a bummer that MDN has nothing. It's interesting in the context of CORB, COEP, COOP and Sec-Fetch metadata.

[chrisdavidmills]

It would be great to find someone to write some similar security resources for MDN.

[wbamberg]

@mozfreddyb , I'm trying to write something about xs-leaks this week! Would you have the time to discuss?

[mozfreddyb]

Happy to! Did you mean here? (If not, please send email, if you want to schedule a call)

After having given talks about xs leaks and Cross-Origin isolation in the last year, my take-away is that most if not all of this is too broad for most audiences (or my talks sucked 😁). What I suggest is that this is split up into specific problems and solutions that are a bit more practical.

There are already articles about CORP, COOP, COEP and Fetch Metadata that can be easily referenced. So, I would go from a specific attack/leak and explain how it's possible, how it's prevented (from first principles) and then point at the aforementioned solutions.

[wbamberg]

I'll send you an email in case it would help to talk, but I've also written something up here. Either we can work it out here or this can be a basis for a chat :). Sorry it is so long.

Context: I'm writing a set of articles for MDN on "attacks". So far I've written one on XSS and one on clickjacking, and have one on CSRF in review (aside: if you wanted to do a tech review of this, I'd greatly appreciate it). Each article is structured roughly in two halves: the first describes the attack, and the second describes defenses.

So next up for me is XS leaks, and the best sources I have found for this as the XS-leaks wiki and the OWASP cheatsheet.

Overall structure

Unlike the other attacks, ISTM that XS leaks describes a whole category of individual attacks, using quite different techniques and countered by different defenses (although there is a core set of defenses that addresses many attacks).

Two options for dealing with this are:

1. write a separate attack/defense guide for every XS-leak attack. I don't want to do this because I think it would be overwhelming, and would structurally tend to bury the other attacks (XSS, etc).

2. write a single guide that covers all the attacks. I don't want to do this because I think it would duplicate the XS-leaks wiki, and I don't see any value in that.

What I think MDN could add to the existing docs is a more accessible overview of the problem, orienting people in it and giving them general guidance that will help to protect them from most attacks, and pointing them to places like OWASP and the XS-leaks wiki, for the full details.

So for an MDN article, I'd like to do something like:

• describe a subset of the attacks described in https://xsleaks.dev/, but say that this is not exhaustive, and point to the wiki for a fuller list
• describe the common defenses we want people to think about, which are, AFAICT:
  1. SameSite=Lax
  2. framing protection with x-frame-options and frame-ancestors
  3. COOP
  4. fetch metadata

(This seems quite similar to the approach taken in the OWASP doc as I see it, in which the OWASP doc describes more or less a subset of attacks. I am a bit worried about simply duplicating info that's available in OWASP, but I do think it is worth having something on MDN for xs-leaks.)

So if we like this general approach, one question is, which attacks from the XS-leaks wiki should we describe on MDN? In the draft PR I have for this, I have included: leaking history using :visited, frame counting, and error events.

I think it is worth describing attacks in enough concrete detail that people can see how they work - I find descriptions that are just given in general terms (e.g. "using a window reference to gain information about a target site" are not very helpful.). That means I don't want to just give a terse list of attacks.

After having given talks about xs leaks and Cross-Origin isolation in the last year, my take-away is that most if not all of this is too broad for most audiences (or my talks sucked 😁). What I suggest is that this is split up into specific problems and solutions that are a bit more practical.

I watched your talk a little while ago, and thought it was very interesting! I'd like to know what made you think it was not successful? My take generally on xs-leaks is that there's a lot to cover and it could easily seem overwhelming (I get that feeling perusing the xs-leaks wiki), which is why I was thinking of evangelising a set of defenses which cover most of the cases, rather than trying to get people to plug all the holes one at a time. A sort of "if you do nothing else, do this" approach. And then referring to the XS-leaks wiki for all the details.

Spectre/Meltdown

Should we treat Spectre/Meltdown and their mitigations as part of the XS-leak docs?

• on the "no" side, the XS-leaks wiki doesn't, nor does the OWASP doc. And it seems this is a large and complex enough topic to warrant its own space.
• on the "yes" side, MDN does consider them xs-leaks (https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/CORP). And IIUC they are fundamentally timing attacks, which are covered in the XS-leaks wiki.

I think "no" - that is, we should have a separate standalone article on Spectre/Meltdown. But I would welcome opinions.

Also though, I'd love to understand better what kind of guidance we should give people regarding these attacks. I understand that as a mitigation, high-res performance.now() and SharedArrayBuffer are only available to sites that implement cross-origin isolation. But as a practical matter, should we recommend that sites implement cross-origin isolation anyway? And if so, how strong should our recommendation be? That is, what is the risk of these attacks if you do nothing?

We should also probably have a standalone article on "implementing cross-origin isloation".

Fetch metadata

Using fetch metadata is quite complex and needs a guide. The best one I found was https://web.dev/articles/fetch-metadata. I'm not sure if MDN should have its own guide on "implementing a resource isolation policy using fetch metadata" or if it's enough just to refer to the web.dev one.

CORB

The XS-leaks Wiki, and MDN, talk about CORB, and MDN links to the Fetch spec where it used to be defined. But it seems to have been removed from the Fetch spec some time ago, in favour of a new approach which hasn't landed yet? I'd love to know the status of this and what we can do about these dangling references, and how if at all we should be talking about CORB in the context of XS-leaks.

[mozfreddyb]

This is so long, I'll have to quote-reply :-)

I agree that xs-leaks is more of a class of attacks than an individual attack and that makes it so hard to grasp. The main challenge is that all of those attacks we've seen are heavily site-dependent. In itself, counting frames across origins is super lame. But if the amount of frames can leak whether a user is logged in with a site makes it more impressive.

What I think MDN could add to the existing docs is a more accessible overview of the problem, orienting people in it and giving them general guidance that will help to protect them from most attacks, and pointing them to places like OWASP and the XS-leaks wiki, for the full details.

So for an MDN article, I'd like to do something like:

* describe a subset of the attacks described in https://xsleaks.dev/, but say that this is not exhaustive, and point to the wiki for a fuller list

* describe the common defenses we want people to think about, which are, AFAICT:
  
  1. SameSite=Lax
  2. framing protection with x-frame-options and frame-ancestors
  3. COOP
  4. fetch metadata

I think it makes sense to explain the concept and give theoretical examples (or link to public write-ups with real-world impact) to then follow with the overall strategy of completely disrupting the cross-site/origin communication channels as an opt-in (through CORP, COEP, COOP, etc.). My personal pet peeve, but maybe worth mentioning:SameSite=lax by default is weaker than samesite=lax when set explicitly

I think it is worth describing attacks in enough concrete detail that people can see how they work - I find descriptions that are just given in general terms (e.g. "using a window reference to gain information about a target site" are not very helpful.). That means I don't want to just give a terse list of attacks.

Yeah, I agree that's still the main challenge

After having given talks about xs leaks and Cross-Origin isolation in the last year, my take-away is that most if not all of this is too broad for most audiences (or my talks sucked 😁). What I suggest is that this is split up into specific problems and solutions that are a bit more practical.

I watched your talk a little while ago, and thought it was very interesting! I'd like to know what made you think it was not successful? My take generally on xs-leaks is that there's a lot to cover and it could easily seem overwhelming (I get that feeling perusing the xs-leaks wiki), which is why I was thinking of evangelising a set of defenses which cover most of the cases, rather than trying to get people to plug all the holes one at a time. A sort of "if you do nothing else, do this" approach. And then referring to the XS-leaks wiki for all the details.

Spectre/Meltdown

Typical security talks start with a "horrible" attack. Maybe the bottom line is that xs-leaks are not really that horrible such that it's hard to sell people on the impact of xsleaks on their page. :)

Should we treat Spectre/Meltdown and their mitigations as part of the XS-leak docs?

* on the "no" side, the XS-leaks wiki doesn't, nor does the OWASP doc. And it seems this is a large and complex enough topic to warrant its own space.

* on the "yes" side, MDN does consider them xs-leaks (https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/CORP). And IIUC they are fundamentally timing attacks, which are covered in the XS-leaks wiki.

I think "no" - that is, we should have a separate standalone article on Spectre/Meltdown. But I would welcome opinions.

Also though, I'd love to understand better what kind of guidance we should give people regarding these attacks. I understand that as a mitigation, high-res performance.now() and SharedArrayBuffer are only available to sites that implement cross-origin isolation. But as a practical matter, should we recommend that sites implement cross-origin isolation anyway? And if so, how strong should our recommendation be? That is, what is the risk of these attacks if you do nothing?

We should also probably have a standalone article on "implementing cross-origin isloation".

I definitely agree and would leave Spectre/Meltdown out of these. I had talks that included the whole CPU-leaks-memory angle and what the browser sandbox does to defeat things on a site-isolation basis and how to go to origin-isolation but this confused the hell out of people. If you want to cover them (with e.g. ,the Origin Agent Cluster header), I would move this to its own page (as you suggest below). However, I have yet to hear from pages that actually make use of Cross Origin Isolation successfully.

Fetch metadata

Using fetch metadata is quite complex and needs a guide. The best one I found was https://web.dev/articles/fetch-metadata. I'm not sure if MDN should have its own guide on "implementing a resource isolation policy using fetch metadata" or if it's enough just to refer to the web.dev one.

I really liked the different isolation policies under https://xsleaks.dev/docs/defenses/isolation-policies/ for this.

CORB

The XS-leaks Wiki, and MDN, talk about CORB, and MDN links to the Fetch spec where it used to be defined. But it seems to have been removed from the Fetch spec some time ago, in favour of a new approach which hasn't landed yet? I'd love to know the status of this and what we can do about these dangling references, and how if at all we should be talking about CORB in the context of XS-leaks.

I think CORB was superseded by ORB (https://github.com/annevk/orb?tab=readme-ov-file), but IIRC annevk stopped pursuing the fetch PR when he left Mozilla. Either way, I think neither is relevant for web devs, as it is a browser-internal architectural decision that explains how resources are blocked and when such that they cannot leak from a network process into a content process. None of that can be controlled by the developer. If you want to add this at all, I would add this as a foot note on a CORS or SOP article to explain why a lot of errors end up appearing as if they were network errors.