W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

[HTML imports]: Imports and Content Security Policy

From: Frederik Braun <fbraun@mozilla.com>
Date: Thu, 09 Jan 2014 16:19:14 +0100
Message-ID: <52CEBDF2.6030909@mozilla.com>
To: public-webapps@w3.org
CC: Gabor Krizsanits <gkrizsanits@mozilla.com>
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
Received on Thursday, 9 January 2014 15:22:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC