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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
17 matches
Mail list logo
