Re: CSP script hashes, inline and src'd

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

Received on Monday, 21 October 2013 17:41:27 UTC