Re: CSP script hashes

If I understand you correctly, the scenario that scares you about hashes is
that WebApp would white list small & potentially harmful snippets such as
`<script>WebApp.delete_account();</script>`.
Assuming that such a snippet has been white listed, an XSS attack can add
such a script, resulting in an account deletion.

While it is theoretically possible that some Web application may add
potentially harmful snippets, I'm not sure that adding such snippets makes
any sense, regardless of the potential security vulnerability with hashes.




On Fri, Feb 1, 2013 at 9:02 PM, Eric Chen <eric.chen@sv.cmu.edu> wrote:

> 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
>