This is a feature, not a bug.

We have always acknowledged the ability for JS to be able to interpose or shim. This is, in fact, the current proposal for polyfilling additional algorithms that are not supported by a UA.

Applications that use the Web Crypto API MUST take into consideration the overall web platform security. This is highlighted in https://dvcs.w3.org/hg/webcrypto-api/raw-file/59866d079030/spec/Overview.html#security , and has been a part of the working draft.

Adding Unforgeable attributes to this object, to seal it, does nothing to meaningfully improve security. If a hostile party is able to inject JS, it's game over, pure and simple. They don't need to replace anything in the Web Crypto API to do so.

> We have always acknowledged the ability for JS to be able to interpose or shim.
> This is, in fact, the current proposal for polyfilling additional algorithms
> that are not supported by a UA.
>
I was also thinking about restricting to overwrite methods would cause
problems to polyfills, but maybe it would be forced to don't allow it
on the ones implemented allowing to add the polyfills for the new
ones, so you can get the hability to add new ones while being
confident calling the native ones are trusted.


> Applications that use the Web Crypto API MUST take into consideration the
> overall web platform security. This is highlighted in
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/59866d079030/spec/Overview.html#security
> , and has been a part of the working draft.
>
I must to admit that didn't read the specification before, but after
reading the section that you has tell me, I'm now more confident
that's a flaw on the specification. I agree that it's non-sense to
share a key between two domains due to the security aspect of doing
so, but if the main reason of developing the Crypto API was to don't
have the flaws of doing encryption using Javascript (speed and
posibility of script injection), if you can't trust on it then it
becames useless and only offer a false sensation of security using it.


> Adding Unforgeable attributes to this object, to seal it, does nothing to
> meaningfully improve security. If a hostile party is able to inject JS, it's
> game over, pure and simple. They don't need to replace anything in the Web
> Crypto API to do so.
>
I was not thinking about third party script injection like the ones
does by some virus or malicious sites, but I was thinking more about
legit sites like Mega or Facebook that are sites with a lot of traffic
by their users and that could use the Crypto API to safely store and
send encrypted data, but maybe due to some bad bussiness strategies or
directly government requeriments (PRISM) could be able to send on 1 of
each 1000 page load petitions (to make it difficult to be find by the
user) a stealth script (I developed them in the past, so I know it's
possible to make the user unaware of them) that change the behaviour
or the Crypto API on that session and append the encryption keys at
the end of each encrypted message and compress them so length don't
raise suspects, and nobody would know it.

I'm not so worry about third party script injections, but about legit
sites that you trust going bad.

(In reply to comment #2)
> > We have always acknowledged the ability for JS to be able to interpose or shim.
> > This is, in fact, the current proposal for polyfilling additional algorithms
> > that are not supported by a UA.
> >
> I was also thinking about restricting to overwrite methods would cause
> problems to polyfills, but maybe it would be forced to don't allow it
> on the ones implemented allowing to add the polyfills for the new
> ones, so you can get the hability to add new ones while being
> confident calling the native ones are trusted.

I'm sorry, if you have script injection, you cannot have any confidence in the code being executed at that point.

For example, they can change the definition of fundamental objects (like Arrays or Functions) to alter expectations about the code that is going to run.

As such, this is explicitly NOT a valid threat or security issue for this API in particular.

> 
> 
> > Applications that use the Web Crypto API MUST take into consideration the
> > overall web platform security. This is highlighted in
> > https://dvcs.w3.org/hg/webcrypto-api/raw-file/59866d079030/spec/Overview.html#security
> > , and has been a part of the working draft.
> >
> I must to admit that didn't read the specification before, but after
> reading the section that you has tell me, I'm now more confident
> that's a flaw on the specification. I agree that it's non-sense to
> share a key between two domains due to the security aspect of doing
> so, but if the main reason of developing the Crypto API was to don't
> have the flaws of doing encryption using Javascript (speed and
> posibility of script injection), if you can't trust on it then it
> becames useless and only offer a false sensation of security using it.

I'm sorry that you waited to read the specification, as it would have hopefully addressed this for you.

It is an explicit NON-GOAL of this WG to deal with the possibility of script injection. That is for the Web App Sec WG.

This WG deals with the speed and correctness of the implementation, but overall platform security is a BROAD problem, and thus suitable for the WG at large. CSP, TLS, Sandboxed iframes, etc are all tools that can be used to deal overall with the security - which is absolutely essential, because this API *cannot* deal with such problems in isolation.

Because the spec *never* claims to deal with script injection, there is no false sense of security. In fact, the section I specifically referred you to tries to make clear the guarantees - and *non* guarantees - we're providing.

> 
> 
> > Adding Unforgeable attributes to this object, to seal it, does nothing to
> > meaningfully improve security. If a hostile party is able to inject JS, it's
> > game over, pure and simple. They don't need to replace anything in the Web
> > Crypto API to do so.
> >
> I was not thinking about third party script injection like the ones
> does by some virus or malicious sites, but I was thinking more about
> legit sites like Mega or Facebook that are sites with a lot of traffic
> by their users and that could use the Crypto API to safely store and
> send encrypted data, but maybe due to some bad bussiness strategies or
> directly government requeriments (PRISM) could be able to send on 1 of
> each 1000 page load petitions (to make it difficult to be find by the
> user) a stealth script (I developed them in the past, so I know it's
> possible to make the user unaware of them) that change the behaviour
> or the Crypto API on that session and append the encryption keys at
> the end of each encrypted message and compress them so length don't
> raise suspects, and nobody would know it.
> 
> I'm not so worry about third party script injections, but about legit
> sites that you trust going bad.

That is explicitly NOT part of the threat model for this API. You MUST trust the site delivering the code. That's simply all there is to it.

If you don't want to trust the site, you can use things like sysapps - http://www.w3.org/2012/sysapps/ - but then you're trusting the SysApp author and the User Agent vendor.

While PRISM is a fun buzzword to invoke, you simply cannot deal with that threat via an API. You may find http://cm.bell-labs.com/who/ken/trust.html a classic paper on this topic.