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

Re: Hashes.

From: Dionysis Zindros <dionyziz@gmail.com>
Date: Thu, 12 Dec 2013 15:58:37 -0800
Message-ID: <CAE-c3memgz+tZXQG+vgGL2hF1JJ_e9G0tkjdWO4j7Due5jhnGQ@mail.gmail.com>
To: Garrett Robinson <grobinson@mozilla.com>
Cc: Joel Weinberger <jww@chromium.org>, Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Neil Matatall <neilm@twitter.com>, Adam Barth <w3c@adambarth.com>, Brad Hill <bhill@paypal-inc.com>, Dan Veditz <dveditz@mozilla.com>
On Thu, Dec 12, 2013 at 3:42 PM, Garrett Robinson <grobinson@mozilla.com> wrote:
> On 12/12/2013 02:11 PM, Dionysis Zindros wrote:
>>
>> Thanks for your feedback. I'm incorporating the requested changes in
>> the attached patch.
>
>
> The only other problem I see with this patch is requesting we print the
> "correct" hash value if a hash values to validate. There's no way to
> determine which inline script an incorrect hash was intended to whitelist,
> so they only solution here is to print the hash of every inline script (for
> every incorrect hash-source in the policy, unless you wanted to add some
> special-case logic to only print them out for the first hash-source that
> failed to validate).

No, the proposed change in the spec says that agents should print the
actual, not the expected, script hash (see definition above). That is,
the hash printed is that which the browser evaluated for the inline
script and which didn't match the one on the HTTP header. For example,
if the header specifies 3 different hashes sha256-A, sha256-B, and
sha256-C, and the inline script is "xxx", then the browser should
print base64(sha256(xxx)) - not A, B, or C.

If the wording does not make that clear, I'd be happy to modify it
with clarifications.

The only thing that remains unclear is which algorithm the browser
should be using here, out of the ones it supports. Perhaps a
clarification is needed for this. However, as most web authors will be
using a single algorithm each (e.g. SHA256), this will only yield one
entry in the developer console based on what the web author is using
on their headers.

The idea is that the developer should be able to understand what the
browser expects to see in the HTTP headers during debug, to fix the
HTTP headers accordingly. Outputting the HTTP header hash in the
console doesn't help - the HTTP header can already be viewed by the
developer, so there's no point in that. The point is to reveal what
the browser thinks the hash of the blocked inline script is, so that
the developer can put that in the header to whitelist their script
easily.

>
> This could create quite a mess in the Developer console (especially if there
> are lots of inline scripts and/or broken hash-sources). I am not sure if
> this would actually be helpful for developers either, and they could just as
> easily copy-paste a one-liner into the Developer Console to do this for them
> (or use a bookmarklet, add-on, etc.)
>
> -Garrett
Received on Thursday, 12 December 2013 23:59:25 UTC

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