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