I really wish they gave just a little more detail on what this attack looks like.
> "Kokatsu showed that if a web application creates a Blob URL with attacker-controlled data, it could lead to XSS attacks – even if the site is protected with strict CSP policies"
Does this mean that your application had to already have the code for Blob URL creation present? Or did it need to have some sort of XSS already available and this attack could be used in conjunction with it?
The former would be amazingly bad coding practices - to let users control what is in a Blob/Data/etc URL via attacker controlled parameters. For the latter, I'm trying to imagine a scenario with "Strict CSP" that would allow you to create and write a Blob URL. With CSPs you have to specify a 'unsafe-inline' value to allow inline Javascript to execute, which wouldn't be allowed with a "Strict CSP".
In this case, it did require the end user being exploited to be enticed to "open this image in a new tab". And it did require bad coding practice. In this case, thinking that their postmessage interface with an iframe was a safe input.
But to their credit they do provide external links with more details. Reading those now, because I'm running into the same questions/ conclusions as you.
I’m yet to find a website that actually has CSP without unsafe inline / eval granted in their policy. I suspect react doesn’t support the policies well, but also that the policy is not as scalable as intended.
Don’t get me wrong, it’s a cool idea but I can’t help but think that it’s dead. Can anyone prove me wrong?
All those sites have a restrictive CSP, among other things. Many of them are Fediverse instances (mostly Mastodon), i.e. complex web services that often serve thousands of users. Some others are simple static sites which are comparatively easy to apply a strict CSP to.
CSPs are hard to get right, but they're doable. Most occurrences of script unsafe-inline and unsafe-eval are due to laziness. As far as I know -- and I use React regularly -- there's nothing about React that makes a strong CSP harder vs normal DOM manipulations.
It's also worth noting that 'unsafe-inline' in CSP is commonly used to support older browsers, and a nonce subsequently disables the unsafe directive for modern browsers that support it. It can be hard to read a policy visually and see if the directive actually applies.
(The same thing happens with 'strict-dynamic' and allowing all HTTP(S) URIs -- 'strict-dynamic' disables the URIs when supported.)
> I suspect react doesn’t support the policies well
Frankly this sounds like something you just made up.
Why would React require any weakening of CSP rules? Is there something special about React that requires loading it differently than any other JavaScript?
On the whole, React is a win for security, because XSS is by default impossible, due to the indirection provided by the Virtual DOM abstraction. As long as you (and your dependencies) don’t dangerouslySetInnerHTML, you’ll eliminate most XSS bugs.
The iframe was created for a different era of the web and it seems to be a constant source of security issues now. Would it be that bad to mark it as deprecated and completely drop support for it in a couple of years?
It is very common for websites to want to include some content from a different site, with a robust security boundary between them. Iframes have issues because security boundaries are hard.
A site that does not want to allow any iframes can already ban them with CSP.
> "Kokatsu showed that if a web application creates a Blob URL with attacker-controlled data, it could lead to XSS attacks – even if the site is protected with strict CSP policies"
Does this mean that your application had to already have the code for Blob URL creation present? Or did it need to have some sort of XSS already available and this attack could be used in conjunction with it?
The former would be amazingly bad coding practices - to let users control what is in a Blob/Data/etc URL via attacker controlled parameters. For the latter, I'm trying to imagine a scenario with "Strict CSP" that would allow you to create and write a Blob URL. With CSPs you have to specify a 'unsafe-inline' value to allow inline Javascript to execute, which wouldn't be allowed with a "Strict CSP".