W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2013

Re: Updated script hash proposal (non spec text)

From: Dionysis Zindros <dionyziz@gmail.com>
Date: Tue, 10 Dec 2013 15:16:16 -0800
Message-ID: <CAE-c3mcFF8-r0GM1W2x902dfQ+ee9UngHOLKvLX=cE8dNz=BJg@mail.gmail.com>
To: Garrett Robinson <grobinson@mozilla.com>
Cc: Neil Matatall <neilm@twitter.com>, Joel Weinberger <jww@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Dec 10, 2013 at 2:55 PM, Garrett Robinson <grobinson@mozilla.com>wrote:

> On 12/10/2013 02:51 PM, Neil Matatall wrote:
>
>> Just wanted to point out an example of this in the wild
>> http://dionyziz.logimus.com/content-security-policy/
>>
>
> Awesome! The Firefox WIP is almost ready to land too. One thing - we only
> support sha256/384/512, due to well known concerns with SHA1's collison
> resistance. This example is using sha1, which it says is the only algorithm
> Chrome supports at the moment. Do we want to spec the supported algorithms
> for 1.1?
>

I'll update the example to add test cases for SHA256/384/512. By the way, I
moved it to an HTTPS/HSTS URL to illustrate good practices, as CSP builds
on the assumption that HTTP headers cannot be tampered with:

https://dionyziz.com/content-security-policy/

However, when building this, I couldn't find the script-hash grammar on the
CSP 1.1 spec. Are there any plans to update the draft soon? It's hard to
get working examples without a spec - one has to dig into the individual
browser source code to see how things are done.

I recommend that we specify SHA256/384/512 on the spec and drop SHA1
completely. There are no backwards compatibility issues here, so there is
no need to support a hash function which might not be collision-resistant.

So, let's update the CSP 1.1 draft to add the grammar for this.


>
>  Check out http://dionyziz.logimus.com/content-security-policy/csp-js.php
>> in Chrome canary with experimental flags set :)
>>
>>
>>
>> On Tue, Dec 3, 2013 at 1:41 PM, Garrett Robinson <grobinson@mozilla.com>
>> wrote:
>>
>>> Attached updated patch to
>>>
>>> 1. create a "base64-value" rule so we don't have to repeat ourselves in
>>> separate "nonce-source" and "hash-source" rules
>>> 2. limit ='s to be a max of 2 and only allowed at the end of the string
>>>
>>> Alternatively, might we just refer to "base64 string from RFC 3548" [0],
>>> the way we do for the "scheme" rule?
>>>
>>> [0] http://tools.ietf.org/html/rfc3548.html#section-3
>>>
>>> -Garrett
>>>
>>> On 11/26/2013 10:57 AM, Joel Weinberger wrote:
>>>
>>>> I, too, support the second option as well (and, in fact, that is how
>>>> we've implemented it for hashes in Chrome).
>>>>
>>>> I don't suppose there's a way to specify that the '=' should only appear
>>>> at the end of the value (and there should be 2 or less)?
>>>> --Joel
>>>>
>>>>
>>>> On Mon, Nov 25, 2013 at 11:09 AM, Garrett Robinson
>>>> <grobinson@mozilla.com <mailto:grobinson@mozilla.com>> wrote:
>>>>
>>>>      On 11/25/2013 01:24 PM, Neil Matatall wrote:
>>>>      > Ah yes. Oops. I support the second option as well.
>>>>      >
>>>>      > Should "1*( ALPHA / DIGIT / "+" / "/" / "=" )"  be its own
>>>>      > symbol/definition/whatever to make it clear that the values will
>>>> have
>>>>      > the same rules?
>>>>
>>>>      I was thinking of doing that, but wasn't sure how to write it in
>>>> the
>>>>      spec. Can we just call it base64-value?
>>>>
>>>>
>>>>
>
Received on Tuesday, 10 December 2013 23:17:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:03 UTC