Re: CSP script hashes, inline and src'd

On Fri, Oct 18, 2013 at 5:45 PM, Joel Weinberger <jww@chromium.org> wrote:

> I'm currently working on the Chromium implementation of script hashes, and
> I came across a point needing clarification: should script hashes apply to
> src'd scripts as well as inlined ones? One of Neil's comments implies only
> inlined, which is my preference, but I want to make sure we're explicit
> about this.
>
> The problem is if they apply to src'd scripts as well, we (Chromium) have
> a chicken and egg
> problem. We check CSP to see if a resource URL is acceptable
> according to the policy. If not, we do not make the request. However, that
> means
> that if the URL is not acceptable *but* the hash of the script *is*
> acceptable,
> we never see the script, and thus can't override the URL decision.
>

Are you referring to CSP's script nonces? If so, then the spec doesn't seem
to distinguish inline from sourced scripts, and also doesn't treat a nonce
as a hash to be verified.

"Note that the nonce's value is *not* a hash or signature that verifies the
contents of the script resources. It's quite simply a random string that
informs the user agent which scripts were intentionally included in the
page.

Script elements with the proper nonce execute, regardless of whether
they're inline or external. Script elements without the proper nonce don't
execute unless their URLs are whitelisted. Even if an attacker is able to
inject markup into the protected resource, the attack will be blocked by
the attacker's inability to guess the random value."


>
> This isn't a fundamental limitation of Chromium, but I'm not sure of the
> true
> value of applying script hash to src'd content, and it would mean
> requesting extra resources that CSP otherwise would block. Additionally, on
> a practical level, it would require a heck of a lot of refactoring on our
> end.
>
> Whatever our decision, I'm working on a more formal spec write to clarify
> some of the ins and outs and what-have-yous that I've come across during
> implementation. Obviously, whatever the consensus here is will be a part of
> that.
>  --Joel
>