Re: HTML Imports and CSP

+1 I am with you now Crispin!

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

On Apr 2, 2015, at 2:28 PM, Crispin Cowan <crispin@microsoft.com> wrote:

  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 <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> 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> wrote:



On Wed, Apr 1, 2015 at 11:53 PM Mike West <mkwst@google.com> wrote:

  On Thu, Apr 2, 2015 at 6:32 AM, Devdatta Akhawe <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