Re: Threats to primary use cases from malicious client-side scripts

On Thu, Jun 14, 2012 at 8:15 PM, Ryan Sleevi <sleevi@google.com> wrote:
> I think my basic premise is that servers should trust it only as much as
> they trust any other data from the user. Fundamentally, I'm not sure this
> attack is any different than attacks on say, <keygen>, since a malicious
> client script could remove the <keygen> element from the <form>, then insert
> an <input type="hidden"> element with the same name as the <keygen> tag and
> with a malicious SPKAC.

Agreed.  As it happens, I almost simultaneously posted this very
observation to the HTML5 list as it strikes me that this is a
particularly undesirable vulnerability in <keygen>.

> Broader security measures seem more appropriate for Web App Sec and related
> (eg: CSP as an XSS mitigation, etc)

Good point; however, the server cannot be certain that the client
supports/obeys CSP - whereas receiving generated keys in a header that
cannot be modified by client-side script would provide assurance that
the key was not modified, whether CSP is supported or not.

> No, I think you're very much correct in the threats. That's why I keep
> hand-waving over "the web security model". If you think Carol or Charlie's
> web service is really a front for Mallory, then you certainly don't want to
> trust their scripts either.
>
> In some sense, I think these use cases may be more desired in the context of
> things like the System Applications WG
> ( http://www.w3.org/2012/05/sysapps-wg-charter.html ) or for the Web
> Applications WG ( http://www.w3.org/2008/webapps/ ), both of whose security
> models provides a slightly different set of guarantees that may allow Alice
> and Bob to securely communicate.

Which suggests that this should be removed from the list of primary
use cases for webcrypto... which I'm sure cannot be right?
Personally, I would very much like to see a solution for this use case
as part of this project.

> However, when you also factor in protocols like WebSockets and WebRTC's
> transports, I think you do start to see some use cases that can be met in
> existing model. For example, Alice could contact wss://mallory/chat_script ,
> and Bob could contact wss://mallory/chat_script . wss:// only guarantees
> that Alice<->Mallory and Bob<->Mallory are protected, but says nothing about
> Alice<->Bob. Alice and Bob could use this API to negotiate secrets, without
> necessarily requiring them to trust wss://mallory (or any script content
> from her)

I don't think one necessarily need factor in WebSockets: could one not
substitute a simple store-and-forward messaging system over HTTP
(which happens to be the use case in which I am presently most
interested)?

Krs,
-- Alan

Received on Thursday, 14 June 2012 20:19:35 UTC