Re: [HTML imports]: Imports and Content Security Policy

Hi Frederik,
Thanks for bringing it up!

As you pointed out, CSP of imported documents essentially extends the
set of allowed domains. I thought I was useful for component authors to
specify their own domains, like one of their own CDN.

I'm not sure how it is threatening because components won't have any
sensitive state in it
because HTML Imports doesn't have any isolation mechanism after all. It
however might be an optimistic view.

Being conservative, it could be better to apply master document's CSP to
whole import tree
and ignore CSPs on imports. It is less flexible and page authors need to
list all domains for
possibly imported resources, but this flat model looks what Web is relying
today.

I'd appreciate any feedback and/or suggestions here. It seems there is some
progress on CSP side.
It would be great if there is some new mechanism to handle CSP of
subresources.
Things like ES6 modules might get benefit from it as well.



On Fri, Jan 10, 2014 at 12:19 AM, Frederik Braun <fbraun@mozilla.com> wrote:

> Hi,
>
> I have subscribed to this list because my colleague Gabor (CC) and I
> found a few issues with Content Security Policies applied to HTML imports.
>
> The current draft
> (http://w3c.github.io/webcomponents/spec/imports/#imports-and-csp, Jan
> 9) suggests that import loading is restricted through a script-src
> attribute, which is probably fine.
>
> Our issue, however is with the next layer: "Each import is restricted by
> its own Content Security Policy".
>
> Let's discuss how this could work: The document subtree of the imported
> document has its own CSP, just like the parent document. Hence, there
> are two CSPs guarding one browsing context (i.e. the window object).
>
> This brings the issue that a restricted imported document can ask the
> non-restricted parent document to do its dirty work:
> Imagine a CSP on the parent document (example.com) that only allows
> example.com and imported.com. The CSP on imported.com allows only
> imported.com ('self'). The imported document could easily contain a
> script that attaches a script node to the parent document's body (other
> subtree) which loads further resources from example.com. The restriction
> against imported.com has been subverted, hasn't it?
>
> If we interpreted this more freely, we could also consider combining the
> two CSPs somehow, let's see how this could work:
>
> Scenario A) The CSP of the main and the imported document are loosely
> combined, i.e. the union set is built. The whole document that formerly
> had a policy of "default-src: example.com" gets a new policy of
> "default-src: imported.com", because the import has this policy specified.
>
> This case brings multiple issues: Allowing resource loads
> depends on whether the web server at imported.com serves its http
> response quickly. This issue is only getting worse with nested imports
> in which imported documents A and B both import another document C -
> which chain up to the parent is the correct one? Via A or B?
>
>
> Scenario B) The CSP of the main and the imported document are forming a
> strict combination (intersection): The CSP on the imported document
> (imported.com) would then have to explicitly allow example.com,
> otherwise including it would break the importing site. This is unlikely
> to be intended. The previous example with imported documents A and B
> that both import C applies makes it impossible to solve.
>
>
> Now, what seems to make sense instead is that the CSP of the imported
> website is completely *disregarded*. This would lead to the sad fact
> that the importer (example.com) cannot treat imported.com entirely as a
> black box, as it has to inspect which resources it intends to load and
> selectively allow them in their own CSP. On the other hand, this
> wouldn't bring any of the previously mentioned side-effects. The actual
> owner of the document is fully in charge.
>
>
>
> What do you think?
> Frederik
>
>
>


-- 
morrita