search

w3c / webappsec-csp

WebAppSec Content Security Policy
https://w3c.github.io/webappsec-csp/
Other
209 stars 78 forks source link

Resolving 'self' within srcdoc iframe #405

Open ckerschb opened 5 years ago

ckerschb commented 5 years ago

Brief Summary: Assume a srcdoc iframe which applies a meta CSP using the keyword 'self'. What should 'self' resolve to?

Details from a discussion with Boris: what's supposed to happen here per spec is that we land in https://html.spec.whatwg.org/multipage/semantics.html#attr-meta-http-equiv-content-security-policy which calls into https://w3c.github.io/webappsec-csp/#parse-serialized-policy and then that's it. At no point does it set the self-origin of the policy.

Compare this to https://w3c.github.io/webappsec-csp/#set-response-csp-list which does the parsing via https://w3c.github.io/webappsec-csp/#abstract-opdef-parse-a-serialized-csp-list (which calls https://w3c.github.io/webappsec-csp/#abstract-opdef-parse-a-serialized-csp on each comma-separated thing) and then sets a self-origin on the policy...

That said, I don't understand how https://w3c.github.io/webappsec-csp/#csp-header (which just does the parse and does not set self-origin) interacts with any of this. Is that part of the spec meant to be informative? But it's using "MUST". And if it's normative, how does it fit into the processing model? Seems to me that given that fetch calls into https://w3c.github.io/webappsec-csp/#set-response-csp-list from https://fetch.spec.whatwg.org/#main-fetch step 10, that's the actual processing model and the text in https://w3c.github.io/webappsec-csp/#csp-header should be removed or changed to be informative...

Anyway, the upshot is that as the spec is currently written policies don't have a defined self-origin. We should fix that in the spec, and in any case I'd need to see the definition for what it should be before I can propose a sane way of getting at it in Gecko code.

When defining it, we should make sure to consider the following case: A page window.opens a blob: or data: page, then navigates itself to a different origin, then the blob: or data: inserts a . What should the self-origin for that be and why?

ckerschb commented 5 years ago

@mikewest

bzbarsky commented 5 years ago

Anyway, the upshot is that as the spec is currently written policies don't have a defined self-origin.

<meta> policies. HTTP-delivered policies do have one, modulo that business with https://w3c.github.io/webappsec-csp/#csp-header

bzbarsky commented 5 years ago

then navigates itself to a different origin, then the blob: or data: inserts a . What should the self-origin for that be and why?

"inserts a <meta csp>. What should the self-origin for that <meta csp> be and why?"

Thank you github for just stripping out the relevant parts of the comments... ;)

annevk commented 5 years ago

Note that you cannot create a popup for a data: URL (at least in Chrome and Firefox this results in a network error), but a blob: URL should work. Given that the blob: URL has its own origin, why can the self-origin not be that? (That is, the same as-if you navigate to a blob: URL directly.)