Re: HTML Imports vs unsafe-inline

'unsafe-static-inline' does look like it'd work.

Re the concern about developers shooting themselves in the foot, I
think 'unsafe-static-inline' would be an improvement over the current
situation. Right now, developers who run into the inline-script
prohibition can add 'unsafe-inline', opening themselves up to DOM
attacks too, or they can add a hash or nonce. Ironically, a hash or
nonce is _easier_ to produce for a dynamic script containing a
server-side XSS than for a static script since there's already code
running over the dynamic script. It'd be nice to make static scripts
just as easy to whitelist.

Re Joel's point (https://crbug.com/393307#c15) that developers could
just live with an extra reload of the app/site for each change to the
javascript, I think it's clear why that would be unfortunate.

Thanks,
Jeffrey

On Thu, Sep 11, 2014 at 5:09 AM, Mike West <mkwst@google.com> wrote:
> +abarth
>
> Yes. Imports are weird.
>
> I don't think there would be significant increase in risk to allow inline
> scripts in an Import file, as you already need to whitelist the file itself
> via 'script-src' (it's not clear to me how to express that clearly in spec
> text, but that's hardly a concern worth considering).
>
> I'm glad you suggested this, because it reminds me that I'm on the hook to
> send a proposal to the list regarding the discussion on
> https://crbug.com/393307, where Adam proposed a 'unsafe-static-inline'
> source expression that allowed inline content from a non-script created
> parser for exactly the Chrome Apps use case you're pointing out.
>
> The idea is that the risk associated with 'unsafe-inline' is mitigated if
> there's no dynamic content. Packaged resources could be considered "static"
> in some sense, so the inline script risk would only come from DOM-based
> injection, rather than raw inline injection via server-side bugs.
>
> I think it's an interesting proposal, but one I'm reluctant to expose to the
> web. Folks would fairly easily shoot themselves in the foot if they were
> allowed to claim that a dynamic resource was static in the relevant sense.
>
> -mike
>
> --
> Mike West <mkwst@google.com>
> Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
>
> On Thu, Sep 11, 2014 at 6:19 AM, Jeffrey Yasskin <jyasskin@google.com>
> wrote:
>>
>> HTML Imports are a great way to import javascript, but the simple way
>> to use them requires unsafe-inline:
>>
>> https://code.google.com/p/chromium/codesearch/#chromium/src/third_party/WebKit/Tools/GardeningServer/lib/update-util.html.
>> It's possible to split each file in two, but that's inconvenient while
>> editing and costs network requests. It's also possible to write a
>> build step that generates hashes for each script, but injecting a
>> build into the edit/debug cycle slows that cycle down.
>>
>> Is there something the CSP spec could do (either a new token or advice
>> to authors) that would make these literal scripts easier to use
>> without opening vulnerabilities?
>>
>> This is also relevant to Chrome Apps, which force a CSP to protect
>> their users: https://developer.chrome.com/apps/contentSecurityPolicy.
>> If there's something halfway to unsafe-inline that would still avoid
>> the relevant vulnerabilities but would allow use of literal <script>
>> tags, it'd be nice to let people use Polymer more easily.
>>
>> Unfortunately, I don't have a concrete suggestion here, partly because
>> I don't understand the attacks that the inline-script restrictions are
>> intended to defend against.
>>
>> Jeffrey
>>
>

Received on Thursday, 11 September 2014 18:24:03 UTC