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

Re: CSP script hashes

From: Nicholas Green <ngreen@twitter.com>
Date: Fri, 1 Feb 2013 10:32:40 -0800
Message-ID: <CADYSid_-GVnb-Nd8r9zkOcSdteJ5H1J8U1Oo3kQfWsLbLUjhQQ@mail.gmail.com>
To: Eric Chen <eric.chen@sv.cmu.edu>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
Not 100% sure I follow your scenario.  The attacker cannot run inline
script unless the script's hash is in our headers, and we generate
those headers at deploy time.  It's important to note: the appeal of
this strategy to me is that I have seen no valid use case for
dynamically generated scripts, so we would only have hashes of static
assets that we generate at deploy time and inline for performance
reasons.  I am not suggesting we dynamically hash the script tags in a
page as we generate it. That would be bad.

What we would protect agains is the invocation of dangerous methods.
So is the vector you are suggesting a DOM XSS calling code provided by
a hashed inline script?  That seems feasible, but that is possible
with nonced scripts as well I think.  Could you elaborate? I think I'm
missing something important here.

On Fri, Feb 1, 2013 at 10:19 AM, Eric Chen <eric.chen@sv.cmu.edu> wrote:
> One key difference between nonces and hashes is that hashes can't stop
> return-to-libc-like attacks (e.g.,, attacker calling
> twitter.delete_my_account() which could be hashed).
> On Thu, Jan 31, 2013 at 5:32 PM, Nicholas Green <ngreen@twitter.com> wrote:
>> Hi folks,
>>   There has been some discussion around hashes rather than nonces for
>> <script>/<style>s recently, and I wanted to support that suggestion.
>> My proposal would be we send down a header of script-hashes <hash>
>> <hash> ..., that specifies which scripts can run on a page.  This is,
>> I think, what ISSUE-36 proposes.
>>   The reason this is appealing to us is that the only real blockers
>> that we have encountered while implementing CSP headers that restrict
>> inline scripts and styles are:
>> 1) Scripts that must be run at a certain time during page load.
>> 2) Styles that should be applied from initial page load.
>> 3) Scripts and styles that are inlined for performance reasons (i.e.
>> to avoid an extra round trip on high latency connections).
>>   None of these require any dynamic content to be present in the
>> scripts or styles, thus script hashes, which could either complement
>> or work independently of script nonces, that allowed us to specify the
>> hashes of scripts that we will allow to run inline would be
>> sufficient.  Since the content is static these hashes can be
>> calculated at the deploy time (light on the server), and don't need to
>> be salted with any server side secrets, this should be relatively
>> straightforward.  Of course some details (i.e. ignore whitespace?)
>> would have to be specified to ensure interoperability.  I realize this
>> will be non-trivial to implement for some applications, but think the
>> benefit is worth it.  It certainly would be from our perspective.
>>   One last point: Since assets are often served from CDNs generating
>> random nonces per request may be tricky, but if we just need to change
>> headers each time we change assets, I think we dodge the CDN
>> difficulties as well as potential caching issues.
>>   Thoughts?  Implementation hurdles?  Other places this is already
>> covered that I should've read?
>> Thanks,
>> Nick
> --
> -Eric
Received on Friday, 1 February 2013 18:38:46 UTC

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