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

On Thu, Jun 14, 2012 at 1:18 PM, Alan Egerton <eggyal@gmail.com> wrote:

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

I don't believe this necessarily represents a vulnerability in <keygen>,
just a risk that depends on how and to what purpose it's used for.This is
the general, "hard" problem of online provisioning protocols.



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

That may protect the key, but it does nothing to protect any other part of
the form data, all of which may be as-or-more security relevant to the user
and the site operator.

For example, imagine the form is creating a new user, where a new key is
being associated, but there's also an "Is Admin" box being checked. An
attacker could XSS set the "Is Admin" box, which would also presumably be
of security relevance.


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

No, I'm not suggesting removing them. I'm just providing examples of how
the security model might change. However, concrete examples of how it might
be used today I gave below. It was more of a "Yes, this may be only worth X
now, but with these coming down the pipeline, it will be worth 3X 'real
soon now'"


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

It depends. How are you doing the store and forward? XMLHttpRequest?

I was wanting to point out APIs that allow cross-origin communication
without changing the script origin model.