[HN Gopher] CSP bypass: How one Chrome XSS bug took 2.5 years an...
       ___________________________________________________________________
        
       CSP bypass: How one Chrome XSS bug took 2.5 years and an HTML spec
       change to fix
        
       Author : weinzierl
       Score  : 55 points
       Date   : 2021-06-22 13:57 UTC (9 hours ago)
        
 (HTM) web link (portswigger.net)
 (TXT) w3m dump (portswigger.net)
        
       | strictnein wrote:
       | 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 wrote:
         | Agreed.
         | 
         | 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 wrote:
         | The example exploit of chat.mozilla.org helped me understand:
         | 
         | https://keerok.github.io/2021/05/20/mozilla-xss/
         | 
         | It has a link to a video:
         | 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.
        
       | hsbauauvhabzb wrote:
       | 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?
        
         | ezekg wrote:
         | 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.
        
         | ianopolous wrote:
         | We use quite strong CSP for https://beta.peergos.net
         | 
         | Most of the site is written is vuejs and yes you need to
         | precompile the vuejs templates for it to work with this strong
         | CSP.
        
         | TechBro8615 wrote:
         | > I suspect react doesn't support the policies well
         | 
         | Is this a suspicion based on evidence or any form of analytical
         | reasoning? Frankly it 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.
        
       | gregschlom wrote:
       | 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?
        
         | jefftk wrote:
         | 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.
        
         | merb wrote:
         | you know iframe's can be sandboxed (still not the default
         | tough)
        
       | thayne wrote:
       | Are other browsers affected?
        
       ___________________________________________________________________
       (page generated 2021-06-22 23:01 UTC)