1803475 - Content-Security-Policy schemeless host expressions don't match in srcdoc iframes (and iframes src=data:...)

Status: NEW

(Core :: DOM: Security, defect, P3)

Description

[mattheww]

Attachment: Example page

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/109.0

Steps to reproduce:

Create an iframe with a srcdoc attribute, or with a data: src attribute. The srcdoc html should have a <meta http-equiv="Content-Security-Policy"> tag with a host source, e.g. default-src: example.com;.

Actual results:

The specified host is not allowed through CSP.
(Note that if you add a scheme to make it a proper URL, e.g. default-src: http://example.com, it works.)

Expected results:

The host should be allowed through CSP. The specification says that host sources should "[match] any resource on the host, regardless of scheme", and Chrome and Safari also allow it.

Comment 1

[mattheww]

Attachment: Example without JS

Whoops, here's what it's supposed to look like after the script runs.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Daniel Veditz [:dveditz]]

I can reproduce this. and I see the problem with BOTH frames. The second one uses regular src= on a data: document which shows it's not srcdoc that is the source of the problem, and is a clue.

If you load the data: URL as a top-level document the gravatar is also blocked

When loaded from a file:/// URL Chrome also blocks both images, and chrome blocks the Gravatar when loaded as a top-level data: document.

The most relevant part of the spec is §6.7.2.6. Does url match expression in origin with redirect count?. Step 3.2 says

If expression does not have a scheme-part, and origin’s scheme does not scheme-part match url’s scheme, return "Does Not Match".

That explains why Chrome and Firefox correctly block the image in the file: and top-level data: cases -- those schemes don't match the url.

I suspect in the srcdoc case we may be taking the scheme from the location ("about:srcdoc") rather than the origin (inherited from the parent document). That would be a bug.

In the data: case the "origin" is "opaque" and we're arguably doing the correct thing, at least per this tiny section of spec taken out of context. Chrome may be treating data: similarly to the way they do sandboxed frames, inheriting the parent's origin at least as a reference for loading things. That might be more useful, or it might be wrong. If that's the case it should have effects other than this one case we can test -- or we can ask them.

Comment 4

[Tom S]

I suspect in the srcdoc case we may be taking the scheme from the location ("about:srcdoc") rather than the origin (inherited from the parent document). That would be a bug.

Yes, that is the case. We take the scheme from the mSelfURI, which in this case is "about". What we should probably do is stop looking at the mSelfURI in the parser altogether and instead check the scheme during the evaluation of the CSP directive.

Comment 5

[Daniel Veditz [:dveditz]]

Will this get fixed by the work in bug 1804145, or is it merely "similar"?

Comment 6

[Tom Schuster]

(In reply to Daniel Veditz [:dveditz] from comment #5)

Will this get fixed by the work in bug 1804145, or is it merely "similar"?

No this will not fix it. We still do the same wrong comparison as before, only the serialization changed.

Comment 7

[Tom Schuster]

We need to move away from just using mSelfURI and instead move to what the spec calls self-origin.

As an example in bug 1721296 we have an <iframe srcdoc=...> for that we compute mSelfURI as just about:srcdoc, but that never matches *anything. We should probably use the origin of the embedder in that case.

Comment 8

[Tom Schuster]

We currently don't have the resources to fix this bug considering there is an easy workaround (just add the host explicitly besides 'self') and this being a seemingly uncommon situation.