Re: [HTML imports]: Imports and Content Security Policy
On 03.02.2014 21:58, Hajime Morrita wrote: Parser-made script means the script tags and its contents that are written in HTML bytestream, not given by DOM mutation calls from scripts. As HTML Imports doesn't allow document.write(), it seems safe to assume that these scripts are statically given by the author, not an attacker. I don't see how this mitigates XSS concerns. If we allow inline script there's no way to tell if the imported document has intended or injected inline scripts. Imagine an import that includes something like import.php?userName=scriptalert(1)/script.
Re: [HTML imports]: Imports and Content Security Policy
Good point. My thinking is that I want somehow make HTML imports more like script than HTML. What we need might be a separate content type than text/html for HTML imports. It will prevent accidental inclusion of non-import HTML that is more likely to have XSS hole. We already has CORS to prevent that kind of thing. But owning different content type will be stronger protection. On Tue, Feb 4, 2014 at 12:22 AM, Frederik Braun fbr...@mozilla.com wrote: On 03.02.2014 21:58, Hajime Morrita wrote: Parser-made script means the script tags and its contents that are written in HTML bytestream, not given by DOM mutation calls from scripts. As HTML Imports doesn't allow document.write(), it seems safe to assume that these scripts are statically given by the author, not an attacker. I don't see how this mitigates XSS concerns. If we allow inline script there's no way to tell if the imported document has intended or injected inline scripts. Imagine an import that includes something like import.php?userName=scriptalert(1)/script. -- morrita
Re: [HTML imports]: Imports and Content Security Policy
On 31.01.2014 06:43, Hajime Morrita wrote: Generally I prefer master-CSP model than the own CSP model due to its simplicity but I agree that unsafe-script kills the conciseness of Imports. To make inline scripts work with imports, we might want another CSP directive like safe-script, which allows parser-made script but doesn't allow dynamic ones. There is some room to talk what should be allowed as safe-script though. My gut feeling is A) script: Allowed, but B) inline event handlers: Not allowed. What is a safe script? What do you mean by parser-made script tags? We must be careful not to allow bypassing CSP with a simple XSS. Does this make sense?
Re: [HTML imports]: Imports and Content Security Policy
On Mon, Feb 3, 2014 at 2:23 AM, Frederik Braun fbr...@mozilla.com wrote: On 31.01.2014 06:43, Hajime Morrita wrote: Generally I prefer master-CSP model than the own CSP model due to its simplicity but I agree that unsafe-script kills the conciseness of Imports. To make inline scripts work with imports, we might want another CSP directive like safe-script, which allows parser-made script but doesn't allow dynamic ones. There is some room to talk what should be allowed as safe-script though. My gut feeling is A) script: Allowed, but B) inline event handlers: Not allowed. What is a safe script? What do you mean by parser-made script tags? We must be careful not to allow bypassing CSP with a simple XSS. Forget about safe. I tried to give some name to the notion. Parser-made script means the script tags and its contents that are written in HTML bytestream, not given by DOM mutation calls from scripts. As HTML Imports doesn't allow document.write(), it seems safe to assume that these scripts are statically given by the author, not an attacker. I agree that we should be careful here though. We need to take care of innerHTML somehow for example. Does this make sense? -- morrita
Re: [HTML imports]: Imports and Content Security Policy
On 30.01.2014 19:53, Scott Miles wrote: I'm hoping there are some
constraints we can impose on imports to allow
them to contain inline scripts to exist under CSP.
That's interesting. Wouldn't this violate the CSP spec?
Imported scripts still have access to the same origin as the master
document, don't they?
Failing that, we already have a tool ('vulcanizer') which can separate
scripts out of imports (and to the reverse as well).
I really don't understand what this means. Can you please elaborate?
Whether an import uses inline or external scripts is invisible to the
importer.
Re: [HTML imports]: Imports and Content Security Policy
One more thing that little bit worries me, that the most common request when it comes to CSP is banning inline scripts. If all the imports obey the CSP of the master, which I think the only way to go, that also probably means that in most cases we can only use imports those do not have any inline scripting either... I think this should be mentioned in the spec. Since if you develop some huge library let's say, based on imports, and then no costumer can use it who also want to have CSP, because it's full of inline scripts, that would be quite annoying.
Re: [HTML imports]: Imports and Content Security Policy
I'm hoping there are some constraints we can impose on imports to allow
them to contain inline scripts to exist under CSP.
Failing that, we already have a tool ('vulcanizer') which can separate
scripts out of imports (and to the reverse as well).
Whether an import uses inline or external scripts is invisible to the
importer.
On Wed, Jan 29, 2014 at 5:47 PM, Gabor Krizsanits
gkrizsan...@mozilla.comwrote:
One more thing that little bit worries me, that the most common request
when it comes to CSP is banning inline scripts. If all the imports obey the
CSP of the master, which I think the only way to go, that also probably
means that in most cases we can only use imports those do not have any
inline scripting either... I think this should be mentioned in the spec.
Since if you develop some huge library let's say, based on imports, and
then no costumer can use it who also want to have CSP, because it's full of
inline scripts, that would be quite annoying.
Re: [HTML imports]: Imports and Content Security Policy
The security objection to the original own CSP design was never fully
developed - I'm not sure it's necessarily a show-stopper.
Nick
On 30 January 2014 18:53, Scott Miles sjmi...@google.com wrote:
I'm hoping there are some constraints we can impose on imports to allow
them to contain inline scripts to exist under CSP.
Failing that, we already have a tool ('vulcanizer') which can separate
scripts out of imports (and to the reverse as well).
Whether an import uses inline or external scripts is invisible to the
importer.
On Wed, Jan 29, 2014 at 5:47 PM, Gabor Krizsanits gkrizsan...@mozilla.com
wrote:
One more thing that little bit worries me, that the most common request
when it comes to CSP is banning inline scripts. If all the imports obey the
CSP of the master, which I think the only way to go, that also probably
means that in most cases we can only use imports those do not have any
inline scripting either... I think this should be mentioned in the spec.
Since if you develop some huge library let's say, based on imports, and
then no costumer can use it who also want to have CSP, because it's full of
inline scripts, that would be quite annoying.
Re: [HTML imports]: Imports and Content Security Policy
The security objection to the original own CSP design was never fully developed - I'm not sure it's necessarily a show-stopper. Nick Well, consider the case when we have the following import tree: I1 | | I2 I3 | | I4 Respectively CSP1, CSP2, CSP3. CSP2 allows I4 to be loaded but CSP3 does not. So what should we do with I4? If I2 comes first it will allow I4 to be loaded and then I3 will get it as well, even though it should not. If I3 comes first then it won't be loaded... But let's say we eliminate the ordering problem by loading I4 and for I3 we just return null for the import something. What about: I1 | | I2 I3 | | I4 | | I5 I6 Now let's say CSP2 allows I5 but not I6 and CSP3 allows both I5 and I6 (or even worse allows I6 but not I5). Now it we look at I5 from I2 we should get a different imported document than looking at it from I3... To fix this problem we can just completely ignore the parents CSP when we determine if a sub import should be loaded or not. But I think that would kind of defeat the purpose of having CSP on the first place... Anyway, maybe I'm missing something but I don't see how the original own CSP could work.
Re: [HTML imports]: Imports and Content Security Policy
Generally I prefer master-CSP model than the own CSP model due to its simplicity but I agree that unsafe-script kills the conciseness of Imports. To make inline scripts work with imports, we might want another CSP directive like safe-script, which allows parser-made script but doesn't allow dynamic ones. There is some room to talk what should be allowed as safe-script though. My gut feeling is A) script: Allowed, but B) inline event handlers: Not allowed. Does this make sense? On Fri, Jan 31, 2014 at 4:32 AM, Gabor Krizsanits gkrizsan...@mozilla.comwrote: The security objection to the original own CSP design was never fully developed - I'm not sure it's necessarily a show-stopper. Nick Well, consider the case when we have the following import tree: I1 | | I2 I3 | | I4 Respectively CSP1, CSP2, CSP3. CSP2 allows I4 to be loaded but CSP3 does not. So what should we do with I4? If I2 comes first it will allow I4 to be loaded and then I3 will get it as well, even though it should not. If I3 comes first then it won't be loaded... But let's say we eliminate the ordering problem by loading I4 and for I3 we just return null for the import something. What about: I1 | | I2 I3 | | I4 | | I5 I6 Now let's say CSP2 allows I5 but not I6 and CSP3 allows both I5 and I6 (or even worse allows I6 but not I5). Now it we look at I5 from I2 we should get a different imported document than looking at it from I3... To fix this problem we can just completely ignore the parents CSP when we determine if a sub import should be loaded or not. But I think that would kind of defeat the purpose of having CSP on the first place... Anyway, maybe I'm missing something but I don't see how the original own CSP could work. -- morrita
Re: [HTML imports]: Imports and Content Security Policy
On 10.01.2014 03:52, Hajime Morrita wrote: 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. Well the loss of convenience is indeed unfortunate. 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. I'm not concerned about state, but it shouldn't be allowed to bypass a CSP (which is stated in a header, after all) by a simple content injection that triggers an HTML Import (XSS is very prevalent and the main reason we're pushing for CSP is to prevent XSS :)) 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. Yes, just to re-emphasize: I think this is the way to go. 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.
Re: [HTML imports]: Imports and Content Security Policy
On Fri, Jan 10, 2014 at 5:30 PM, Frederik Braun fbr...@mozilla.com wrote: On 10.01.2014 03:52, Hajime Morrita wrote: 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. Well the loss of convenience is indeed unfortunate. 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. I'm not concerned about state, but it shouldn't be allowed to bypass a CSP (which is stated in a header, after all) by a simple content injection that triggers an HTML Import (XSS is very prevalent and the main reason we're pushing for CSP is to prevent XSS :)) 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. Yes, just to re-emphasize: I think this is the way to go. Filed: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24268 Although we might come up with better idea, I agree that we should start from safer option. 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. -- morrita
Re: [HTML imports]: Imports and Content Security Policy
To clarify: your example is supposed to be an attack on imported.com, not example.com (we can assume the attacker has control over example.com)? Nick
Re: [HTML imports]: Imports and Content Security Policy
On 10 January 2014 14:08, Frederik Braun fbr...@mozilla.com wrote: Yes, imagine an XSS vulnerability on example.com. Using this to include imported.com shouldn't mean that the CSP in place (which allows imported.com) is suddenly allowing everything that is also mentioned in the policy of imported.com. Sorry I don't follow. In your example, you said the CSP of imported.com was 'self' only.
Re: [HTML imports]: Imports and Content Security Policy
On 10.01.2014 14:51, Nick Krempel wrote: To clarify: your example is supposed to be an attack on imported.com http://imported.com, not example.com http://example.com (we can assume the attacker has control over example.com http://example.com)? Nick Yes, imagine an XSS vulnerability on example.com. Using this to include imported.com shouldn't mean that the CSP in place (which allows imported.com) is suddenly allowing everything that is also mentioned in the policy of imported.com. Quite contrary: If you include imported.com *and* you want to restrict the resources working on your page, example.com (which is what CSP does), you have to explicitly whitelist everything that imported.com brings, otherwise those features won't work.
[HTML imports]: Imports and Content Security Policy
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
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 fbr...@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
