W3C home > Mailing lists > Public > public-webcrypto@w3.org > August 2012

Re: crypto-ISSUE-21: Requiring Content-Security-Policy [Web Cryptography API]

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 20 Aug 2012 07:32:51 -0700
Message-ID: <CACvaWvaK=dCYs9nWMh5+3X=6URQuf-=Yk=2EK5BESaAmby5HUw@mail.gmail.com>
To: Web Cryptography Working Group <public-webcrypto@w3.org>
On Mon, Aug 20, 2012 at 7:18 AM, Web Cryptography Working Group Issue
Tracker <sysbot+tracker@w3.org> wrote:
> crypto-ISSUE-21: Requiring Content-Security-Policy [Web Cryptography API]
>
> http://www.w3.org/2012/webcrypto/track/issues/21
>
> Raised by: Ryan Sleevi
> On product: Web Cryptography API
>
> One of the concerns with exposing the Web Crypto API to applications is the possibility for cross-siste scripting. This was particularly raised during the "signed JS" use cases, as it suggests that signed JS may act as a mitigation against an unauthenticated ephemeral XSS being turned into a persistent, authenticated XSS, by means of corrupting script stored in localStorage.
>
> One way to mitigate this would be to specify that, in order to have this API exposed, applications MUST use CSP [1] and MUST specify a script-src [2] directive of 'self' and object-src directive of 'self'. This would prevent any inline script from being added, and would prevent the use of 'eval' to execute script.
>
> While such solutions are not perfect, they can *significantly* reduce the risk of compromise or misuse. On the other hand, this may prevent some use cases, such as those imagined by the signed JS. A compromise might be to define "Anything that requires a key requires CSP", which would simply permit insecure applications from using key-based operations.
>
> [1] http://www.w3.org/TR/CSP/
> [2] http://www.w3.org/TR/CSP/#script-src
>
>
>

My vote: Prevent *any* of the Crypto interface from being exposed
without there also being a super-locked-down CSP.

I'm not convinced there will be significant speed advantages by
performing hashing in native code, as it's traditionally not big-num
intensive. Rather, JS can do quite well for most common hash
constructions - quite near native performance, particularly when using
Typed Arrays. As such, trying to split the Crypto interface into a
'partial' interface that respects security boundaries such as this
seems overly complex and with little benefit.
Received on Monday, 20 August 2012 14:33:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 August 2012 14:33:19 GMT