Re: HTML Imports vs unsafe-inline

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