1033675 - [CSP] unify behavior of frame-ancestors with CSP spec when documents with unusual schemes like about: and blob:

Status: NEW

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

Description

[Sid Stamm [:geekboy or :sstamm]]

In bug 1031658 bz points out that it's not clear in the CSP spec what to do when a protected document has frame ancestors that are about:srcdoc, about:blank, data:, blob: URIs (etc).

We need to (1) clarify in the CSP spec[0] what to do in these cases, probably for the editor's draft[1] and (2) make sure or fix our implementation to do that.

Currently in gecko, about: and blob: are considered a scheme for the frame-ancestors check, and a CSP that doesn't permit those schemes explicitly will not allow those as ancestors.  But that may not completely make sense since those documents may have inherited an origin from a parent that has an http scheme (for example).  Spec needs clarity, and we need to verify that gecko does what the spec says.

[0]http://www.w3.org/TR/CSP/
[1]https://w3c.github.io/webappsec/specs/content-security-policy/

Comment 1

[Boris Zbarsky [:bzbarsky]]

Please link to the spec issue that was raised?

Comment 2

[Sid Stamm [:geekboy or :sstamm]]

So this is related, but tangental (more about whether srcdoc/blob/etc inherit CSP from their creators): http://www.w3.org/2011/webappsec/track/issues/15

I'm not in tune with the WG's customs so I'll figure out the appropriate method to open an issue for the frame-ancestors case and post a link here as soon as I can.

Comment 3

[Sid Stamm [:geekboy or :sstamm]]

Editors draft says (about source matching in general):
> "If the source expression a consists of a single U+002A ASTERISK 
> character (*), and the URI’s scheme is not of a type designating 
> a globally unique identifier, (such as blob:, data:, or filesystem:) 
> then return does match."
[ https://w3c.github.io/webappsec/specs/content-security-policy/#match-source-expression ]

And in addition:
> "As defined above, special URI schemes that refer to specific pieces 
> of unique content, such as "data:", "blob:" and "filesystem:" are 
> excluded from matching a policy of * and must be explicitly listed. 
> Policy authors should note that the content of such URIs is often derived 
> from a response body or execution in a Document context, which may be 
> unsafe. Especially for the default-src and script-src directives, policy 
> authors should be aware that allowing "data:" URIs is equivalent to 
> unsafe-inline and allowing "blob:" or "filesystem:" URIs is equivalent to
> unsafe-eval."
[ https://w3c.github.io/webappsec/specs/content-security-policy/#source-list-guid-matching ]

This suggests special treatment for those (but not by looking up their origin for source matching, they must actually be declared as valid sources by name [e.g., "data:"] in the CSP).

That doesn't clear up the srcdoc case, which is being discussed on public-webappsec.
[ http://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0018.html ]

I'll update again when an issue gets filed and the wg makes progress on this topic.

Comment 4

[Sid Stamm [:geekboy or :sstamm]]

Garrett: you had volunteered to bring this up in the WG... when an issue for this is raised (and/or when the group decides what to do) would you please post relevant links in this bug?

Comment 5

[Sid Stamm [:geekboy or :sstamm]]

dveditz is going to bring this up again with the wg.  Based on the latest draft of CSP2, blob: should be treated like data: (as we currently treat data:) and srcdoc is still unclear.

Comment 6

[Eric Shepherd [:sheppy]]

May need to mention any behavior changes in Fx for developers when this is fixed.

Comment 7

[Daniel Veditz [:dveditz]]

I opened an issue on the spec to change the language to document origin rather than URL:
https://github.com/w3c/webappsec/issues/311

feedback so far: 
* Mike thinks URLs are a feature so that sandboxed iframes work
* Brad thinks we should definitely use Origin on principle, and _especially_ if it makes sandboxed iframes NOT work (sandboxing is a sign the origin site isn't trusting its own content).

CSP is next scheduled to come up at the WASWG teleconference on June 15, I'll make sure this is on the agenda for a decision. In the meantime I think we should just go with Origin; URL makes no sense.

Comment 8

[Christoph Kerschbaumer [:ckerschb, back on Sept 9th]]

Kate, as discussed can you please follow up with the working group so we can get that fixed?

Comment 9

[Kate McKinley [:kmckinley, :Kate]]

Commented on https://github.com/w3c/webappsec/issues/311

Comment 10

[Christoph Kerschbaumer [:ckerschb, back on Sept 9th]]

This bug is not critical and will most likely not be fixed within this cycle, hence reclassifying.

Comment 11

[Christoph Kerschbaumer [:ckerschb, back on Sept 9th]]

Removing backlog so this bug shows up in our next triage meeting. Given the latest discussions around x-frame-options and frame-ancestors (e.g. Bug 1024557) it might make sense to restructure (rearchitecture) all of our frame-ancestors code and make our implementation match the spec.

Comment 12

[Christoph Kerschbaumer [:ckerschb, back on Sept 9th]]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #11)
> Removing backlog so this bug shows up in our next triage meeting. Given the
> latest discussions around x-frame-options and frame-ancestors (e.g. Bug
> 1024557) it might make sense to restructure (rearchitecture) all of our
> frame-ancestors code and make our implementation match the spec.

So, this one can actually stay in the backlog.