3 ms·

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-

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".

staticassertion 5y ago
Agreed. https://bugs.chromium.org/p/chromium/issues/detail?id=916326#c20 https://bugs.chromium.org/p/chromium/issues/detail?id=916326... 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.
tyingq 5y ago
The example exploit of chat.mozilla.org helped me understand: https://keerok.github.io/2021/05/20/mozilla-xss/ https://keerok.github.io/2021/05/20/mozilla-xss/ It has a link to a video: https://www.youtube.com/watch?v=nmio2rTn38Q https://www.youtube.com/watch?v=nmio2rTn38Q 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.