Re: HTML Imports and CSP

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.

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
>