- From: Dionysis Zindros <dionyziz@gmail.com>
- Date: Thu, 12 Dec 2013 15:58:37 -0800
- 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