RE: HTML Imports and CSP

Which is my point in the other fork of the thread. You *can* mitigate the threats created by mixing code and data, but it is hard, and you had better do it well. Security is easier if you just do not mix code and data.

So, should you always keep code and data separate? Of course not. You should just have a really good reason to mix them.

From: Joel Weinberger [mailto:jww@chromium.org]
Sent: Thursday, April 2, 2015 2:22 PM
To: Jim Manico
Cc: Mike West; Devdatta Akhawe; Justin Fagnani; public-webappsec@w3.org
Subject: Re: HTML Imports and CSP


On Thu, Apr 2, 2015 at 2:19 PM Jim Manico <jim.manico@owasp.org<mailto:jim.manico@owasp.org>> wrote:
Actually, when putting untrusted data into JavaScript context from an inline perspective, the encoding contexts needed are script block, script attribute and script source (from a JS file).  Happy to provide examples.
To clarify, that's true if you already know for sure that you're really 100% positive that you're in an inline context. But in an HTML file, my point is really that "knowing" you're in an inline script context is extremely difficult (unless you're using a super awesome templating framework, such as LINQ or Go which, of course you should be doing :-). Things are much simpler if you're in an external JavaScript file, though.

And from a direct dom perspective, encoding is not needed - just use safe APIs assignments like .value .text.

Aloha,

--
Jim Manico
@Manicode
(808) 652-3805

On Apr 2, 2015, at 2:03 PM, Joel Weinberger <jww@chromium.org<mailto:jww@chromium.org>> wrote:

On Wed, Apr 1, 2015 at 11:53 PM Mike West <mkwst@google.com<mailto:mkwst@google.com>> wrote:
On Thu, Apr 2, 2015 at 6:32 AM, Devdatta Akhawe <dev.akhawe@gmail.com<mailto:dev.akhawe@gmail.com>> wrote:
> Sure, why not? I'm not a huge fan of inline event handlers, but I don't
> think that allowing them (and inline script) in Imports actually increases
> the risk a developer exposes herself to. Do you think that's an incorrect
> analysis?

There is a huge difference in risk of XSS in inline event handlers and
inline scripts. Different types of contexts, nested contexts etc all
are issues. *cough* I think Joel wrote a paper about this :D

You're not wrong there; inline event handlers are bad and they should feel bad.

That said, is the risk really different in kind from just allowing plain old inline script that executes directly? It doesn't seem to be. Allowing one without allowing the other seems capricious.
Yes, there is a different risk. Dev's point is that in JavaScript files, it is much "easier" to sanitize properly on the server. There are many fewer contexts to sanitize for (e.g. JavaScript strings, JavaScript numbers, and JavaScript code). For inline scripts and event handlers, for your sanitization, you not only need to consider all of the JavaScript contexts... but any other context that can possible appear in the document: HTML attributes, HTML CDATA, CSS, etc.

Additionally, is that if we had a good to way to apply policies within JavaScript files, I would definitely argue for granting that capability, but that's not something that we've looked into/thought about. However, we do have a good way to apply policies to HTML documents, and it seems surprising to me that we would deny that capability to developers who are making modules. That is what would seem capricious to me :-)

I agree that implementing this will be difficult, which is why we can split this into two parts (script-src or import-src followed by a separate mechanism for allowing modules to serve up policies).

> There's a difference between supporting a new feature which isn't currently
> covered by any directive, and changing the meaning of a directive that
> already covers a featue.

Again, because of the DOMXSS risk (even just injecting a new inline script tag
without nonce), I think not using a new directive messes up the
security invariants for any CSP adopters.

If we move imports from `script-src` to `import-src`, then sites that currently disallow imports will no longer have that protection. That seems bad.

What's your ideal solution?

-mike