Re: CSP script hashes

Consider that there is an injection vector on the page and the attacker can
inject some content. For the case of script-nonce, the attacker cannot
inject any inline scripts, but for the case of script hash the attacker can
inject <script>a()</script> given this is is a legitimately hashed script.
Usually this is not be a problem but depends on what you are hashing, the
attacker now has the ability to execute any hashed scripts in the page.

Other than that I actually like the idea of using hashes, this could solve
a lot of deployment issues.


On Fri, Feb 1, 2013 at 11:45 AM, Nicholas Green <ngreen@twitter.com> wrote:

> Can you clarify "call a script," since scripts are tags, not methods
> they are not invokable.  Do you mean inject a script tag into the
> page?  To simply execute the script the script's contents must match a
> whitelist, so the browser will only run the script's we specify,
> unless there is some very tricky hash-collision or header injection.
> The contents of the script tag are invokable regardless of CSP
> strategy (nonces or hashes), unless the script is blocked entirely.
>
> The attacker has to already have javascript execution to invoke
> anything, at which point we've failed already, regardless of whether
> or not they choose to invoke javascript that we have written, or they
> choose to write it themselves.
>
> The goal of hash-whitelist is: Only execute the static scripts we have
> inlined and whitelisted.  I do not see the attack you are suggesting.
> FWIW I believe a hashed whitelist of scripts accomplishes the same
> thing you suggest accomplishing with <meta> tags here, but with higher
> assurance that there was no injection on the initial page load:
> http://lists.w3.org/Archives/Public/public-webappsec/2012Nov/0117.html
>
> Lastly I'm not suggesting we replace nonces, but rather add hashing as
> well.
>
> On Fri, Feb 1, 2013 at 10:40 AM, Eric Chen <eric.chen@sv.cmu.edu> wrote:
> >
> >> 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.
> >
> > So in the script-nonce case, each inline script must have a valid nonce
> > attribute in order to execute. But in this case, the inline script
> doesn't
> > have to have a secret attached, it just has to be on the "whitelist".
> This
> > means that the attacker can freely call any hashed script and depends on
> > what you are hashing it can be quite dangerous.
> >
> >>
> >>
> >> 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
> >
> >
> >
> >
> > --
> > -Eric
>



-- 
-Eric