Re: CSP script hashes

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