Re: CSP script hashes, inline and src'd

The proposal was only meant to apply to inline resources, but I don't
want that to stop the discussion :)

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

I think that's fine. The way I see it, the host-source determines
whether a resource should be fetched and the hash verifies the
integrity of the content executing (which seems extensible).

> but I'm not sure of the true value of applying script hash to src'd content

It's been discussed, especially when the code is hosted by a 3rd party
(when self-hosting is not an option). Tanvi?

> it would mean requesting extra resources that CSP otherwise would block

I think this is OK too. An unnecessary load indicates a bug or an
injection. This information would be surfaced by the CSP reports.
Also, this would keep it compatible with how script-nonce would act if
it were applied to src'd scripts.

On Fri, Oct 18, 2013 at 5:20 PM, Glenn Adams <glenn@skynav.com> wrote:
>
> 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
>
>

Received on Saturday, 19 October 2013 00:47:30 UTC