Re: CSP script hashes, inline and src'd

Okay, I'm going to implement and write up script hashes assuming they only
apply to inline scripts. It seems like integrity should be a separate
concern.

However, I'm not sure about nonces. The spec currently states that nonces
should apply to both inline scripts and src scripts, and I'm inclined to
let that stand for now since both Chromium and Firefox have it implemented
as such. If we decide that we should keep both hashes and nonces, maybe it
will be worth revisiting for the sake of consistency, but let's let people
play with them for now.


On Mon, Oct 21, 2013 at 10:41 AM, Tanvi Vyas <tanvi@mozilla.com> wrote:

> I would really like to see a hashing mechanism for sourced scripts.  I'm
> not sure whether or not this belongs in script-hash and CSP 1.1 today.
>  Definitely we will be able to better define this in the sub-resource
> integrity spec. When we do, it may be an extension of the CSP header and
> script-hash or it may be in the html itself (<script src="
> http://example.com/**script.js <http://example.com/script.js>"
> hash="...">).  Or may be in both.
>
> Here are a couple of use cases:
> * A website may be need to source a third party script, but not have
> complete trust in the third party.  The third party may inject malicious
> code (on purpose or via a hacker).  In order to protect the website, the
> script-hash directive could be set with the hash of the non-malicious
> script.  If the script changes for some reason, the browser would stop the
> script from running on the page.
> * Mixed content - if a website needs to include an external script that is
> over HTTP on an HTTPS page, they could get around the mixed-content
> restriction by requiring an integrity check to make sure the script hasn't
> been intercepted and changed on transit. Note, this wouldn't solve the
> privacy issues involved with mixed content (headers are still sent in the
> clear).
>
> Thanks!
>
> ~Tanvi
>
>
>
>
> On 10/18/13 5:47 PM, Neil Matatall wrote:
>
>> 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
>>>>
>>>
>>>
>
>