762795 - CSP should block based on innermost URI (e.g. view-source, jar)

Status: REOPENED

(Core :: DOM: Core & HTML, enhancement, P5)

Description

[Ashar Javed]

User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5

Steps to reproduce:

"view-source"  shows the source of the page i.e.,  view-source:http://www.mobilefuxx.de. "view-source" URI scheme was unable to load the source code of the page if CSP is in place. 




Actual results:

On http://www.mobilefuxx.de/csp/xsstest/test.php , I have a CSP policy 'self' for every type of resource. If I use:

<iframe src="http://www.mobilefuxx.de/"></iframe>

It works fine because the URI corresponds to 'self'. But if I use "view-source":

<iframe src="view-source:http://www.mobilefuxx.de/"></iframe> 

It does not work & I got CSP Warning (Below you will find). I think it should display the source code because I am asking for source code of URI that corresponds to 'self'.

Warning: CSP: Directive "frame-src http://www.mobilefuxx.de" violated by view-source:http://www.mobilefuxx.de/

Comment 1

[Ashar Javed]

Attachment: Firefox Output of viewsource

POC image shows how Firefox deals with viewsource.

Comment 2

[Ashar Javed]

Attachment: Chrome Output of viewsource

POC image shows how Google Chrome deals with viewsource.

Comment 3

[Sid Stamm [:geekboy or :sstamm]]

"view-source:http://foo.com" is a different URI than "http://foo.com" so CSP is blocking the load because the scheme "view-source:" is not whitelisted.  If you want to allow it, you need to explicitly whitelist the view-source: scheme in your CSP.

As far as I can tell, this is intended behavior.  A page allowing "frame-src 'self'" should not load URIs that are not the same as 'self'.

Comment 4

[Ashar Javed]

Sid, Have you look at the Chrome POC? Chrome implementation of "viewsource" is different then Firefox?

Comment 5

[Devdatta Akhawe [:devd]]

Ashar: IMO, it is a bug in Chrome's implementation. Do you want to file a bug? (I can, but you have the POC)

Comment 6

[Ashar Javed]

Dev, I have filed a bug https://bugs.webkit.org/show_bug.cgi?id=88883, but Adam barth said that it is not an issue. Please look at it.  Thanks!

Comment 7

[Daniel Veditz [:dveditz]]

webkit implements a "viewsource" attribute on the <iframe> element, so the plain src= fits with your filter

Gecko implements a view-source: pseudo-protocol, which as such works anywhere a URL works. They are functionally equivalent, but the way ours is implemented the current CSP spec disallows.

view-source: causes us to to a lot of special-case coding, I'd much rather implement the viewsource attribute and restrict the use to iframes. In particular, in the CSP context allowing a default-src: of view-source: would allow you to load and run scripts from any domain so it's quite dangerous if used incorrectly.

If we don't already have a bug about supporting the viewsource frame attribute I'd file that request instead.

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to Ashar Javed from comment #6)
> I have filed a bug https://bugs.webkit.org/show_bug.cgi?id=88883, but
> Adam barth said that it is not an issue. Please look at it.

we can't see that bug. Please CC me on it--my username (at) gmail.com--if you can, or ask abarth to unhide the bug (since he doesn't think it's a problem anyway)

Comment 9

[Daniel Veditz [:dveditz]]

oops, that's the chrome bug system. use the same address as this bugzilla.

Comment 10

[Daniel Veditz [:dveditz]]

I'll re-open this as an enhancement while we think about it. De-nesting schemes like view-source: would not match the spec but it would be arguably safer to treat these Gecko-only pseudo-schemes consistently with the way we treat them in the same-origin policy -- after all the actual network load request goes to the innermost URI and the outer view-source: or jar: scheme is just syntax.

The alternative of not fixing this would tend to encourage sites like Ashar's to over-whitelist by including all of view-source:. view-source if added to default-src would be the equivalent of "script-src: *" (assuming a more restrictive script-src wasn't explicitly specified).

Then again, since these pseudo protocols don't exist in other browsers we could assume their use will be limited and not worry about it.

Comment 11

[Devdatta Akhawe [:devd]]

Why don't they exist in other browsers ? Chrome also has the view-source scheme; maybe it doesn't allow the framing of the view-source scheme ?

Comment 12

[Ashar Javed]

Daniel, Now you can see the report on Webkit Bugzilla. Thanks!

Comment 13

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Didn't we solve this problem with Mixed Content Blocker? CSP and mixed content blocker should be using similar logic, AFAICT.

Also, is this related to the issue with data: URLs (bug 878608)?

Comment 14

[Devdatta Akhawe [:devd]]

> The alternative of not fixing this would tend to encourage sites like
> Ashar's to over-whitelist by including all of view-source:. view-source if

Do we know of examples of sites that want to use view-source URIs in iframes? Those are the only ones impacted.

> added to default-src would be the equivalent of "script-src: *" (assuming a
> more restrictive script-src wasn't explicitly specified).

yes. But adding a view-source: to frame-src doesn't have any such threat---only default-src does, and that too in the absence of a proper script-src.

 
> Then again, since these pseudo protocols don't exist in other browsers we
> could assume their use will be limited and not worry about it.

Maybe the longer term fix is to just disable viewsource: pseudoprotocol for non-navigation loads?

Comment 15

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.