1398385 - CSP bypass using innerHTML on a same-origin window

Status: RESOLVED INVALID

(Core :: DOM: Security, defect)

Description

[Jun (Request needinfo for comment, I ignore other updates)]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.79 Safari/537.36

Steps to reproduce:

1 Go to https://test.shhnjk.com/open_csp.html#/by.js?<svg/onload=alert(document.domain)>
2. Click go and wait for a second


Actual results:

DOM-based XSS triggered.


Expected results:

Should it be block by CSP? Does not repro on Chrome.

Comment 1

[Daniel Veditz [:dveditz]]

This used to work correctly. Don't we have testcases for about:blank inheriting CSP? 

It's not some special-case inline SVG problem, <img> demonstrates the problem as well:

https://test.shhnjk.com/open_csp.html#/by.js?%3Cimg%20src=/foo.png%20onerror=alert(document.domain)%3E

Comment 2

[Daniel Veditz [:dveditz]]

(In reply to Jun from comment #0)
> Should it be block by CSP? Does not repro on Chrome.

The URL from my comment 1 reproduces the problem on both Chrome and Safari. The svg version does not.

This appears to be related to the issue described at
https://threatpost.com/microsoft-wont-fix-security-bypass-vulnerability-in-edge/127865/#comment-584509

Although in that particular case we seemed to be doing the right thing while others were not.

Comment 3

[Jun (Request needinfo for comment, I ignore other updates)]

Wow. didn't know that it works on Chrome too. I will check with them too.

BTW, I think there is no about:blank window here. The point here is that if attacker can find Non-CSP page on same origin (this time I used by.js) then CSP is bypassed. Non-CSP page can be any static page like robots.txt, as long as it does not have CSP.

Comment 4

[Jun (Request needinfo for comment, I ignore other updates)]

Chrome thinks that this is more of "script gadget" and current spec does not provide protection against this scenario. So you can close this if you agree. https://bugs.chromium.org/p/chromium/issues/detail?id=764518

Comment 5

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Daniel Veditz [:dveditz] from comment #1)
> This used to work correctly. Don't we have testcases for about:blank
> inheriting CSP? 

I think that never worked. I remember that one of the arguments was, that loading a new window through e.g. in that case window.open(), performs a new top-level load which can be considered as a new page load.

(In reply to Jun from comment #4)
> Chrome thinks that this is more of "script gadget" and current spec does not
> provide protection against this scenario. So you can close this if you
> agree. https://bugs.chromium.org/p/chromium/issues/detail?id=764518

Dan, what do you think about Chrome behavior?

Comment 6

[Christoph Kerschbaumer [:ckerschb]]

Dan, please see comment 5.

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #5)
> (In reply to Daniel Veditz [:dveditz] from comment #1)
> > Don't we have testcases for about:blank inheriting CSP? 
> 
> I think that never worked. I remember that one of the arguments was, that
> loading a new window through e.g. in that case window.open(), performs a new
> top-level load which can be considered as a new page load.

OK, fine: a truly blank "about:blank" doesn't have a CSP. But once the opening window starts writing into it a new document is created and it's no longer "about:blank": it gets the principal of the script writing that new document. _That_ should inherit the CSP at that point.

> (In reply to Jun from comment #4)
> > Chrome thinks that this is more of "script gadget" and current spec does not
> > provide protection against this scenario. So you can close this if you
> > agree. https://bugs.chromium.org/p/chromium/issues/detail?id=764518
> 
> Dan, what do you think about Chrome behavior?

My comments wrt about:blank are off-base for this bug -- that's not what's happening and I jumped to conclusions too soon the first time through. Jun's actually opening an existing document that doesn't have a CSP. In that case this is normal and completely expected behavior. I agree with the Chrome folks, and the various WASWG specs and discussions are well aware of this possibility. That's why we've got proposals like Origin Policy and CSP Embedded Enforcement. When it comes down to it this is simply a "DOM XSS" in the unprotected page, and given it's unprotected this is the expected result.

One thing that _does_ seem odd to me (bordering on wrong) is that the page Jun opens is a plain text file (actually application/javascript, but he uses robots.txt as an example in the Chrome bug), NOT an HTML file. Why do we allow DOM manipulation of a non-HTML file? We've coerced a safe document type into an unsafe one.

Anne: can we justify throwing errors when plain documents are treated as HTML? Other options?

Comment 8

[Boris Zbarsky [:bzbarsky]]

> Why do we allow DOM manipulation of a non-HTML file

Because browsers have allowed it all along, basically.

We used to have more special-cases for "plaintext as HTML" documents but we removed them.

Note that image-as-HTML and video-as-HTML are even more problematic, because UAs rely on being able to modify attributes and styles in them to do things like image zoom and whatnot...

Comment 9

[Anne (:annevk)]

What bz said. I would be a little bit worried about locking down such documents, but if we can think of something it might be worth experimenting with and see if we get any breakage reports.

Comment 10

[Jun (Request needinfo for comment, I ignore other updates)]

Sorry, I have a question (not related to the bug).

My Employer (Microsoft) asked me to CC MSVR on all bugs I file to vendors. This is because they want to make sure that I strictly follow coordinated vulnerability disclosure policy of vendors.

My question is, am I still eligible for bounty even I CC them on bugs I filed? It's bit weird question but Mozilla's point of view, adding them to CC means that bugs are disclosed to externals (MSVR), which I thought might be violation of Mozilla's vulnerability disclosure policy?

If you are okay with adding them to CC and I'm still eligible for bounty, then I will add them to all bugs I found.

Comment 11

[Daniel Veditz [:dveditz]]

If you work for Microsoft then doesn't "Microsoft" already know, in theory at least? Sure, CC them (as we'd allow reporters to CC their partners). Some companies have a problem with their employees "moonlighting" (making money elsewhere), especially if it's using the same skills they were hired for, so make sure it's OK with your bosses.

I think our concern would be if your employer were paying for you to find the bugs the bounty is also paying for, but that would be true whether or not you CC them on the bug. I don't think our policy actually disqualifies anyone for that, though. I'll check with other members of the bounty committee.

Comment 12

[Daniel Veditz [:dveditz]]

This is correct behavior for the current time. If a site doesn't put CSP on all their pages then there may be a way to use that page as part of a CSP bypass.

Something like Origin Policy (possibly renamed Origin Manifest?) or "CSP Pinning" is the solution to this.