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

On Thu, Jun 14, 2012 at 5:40 AM, Alan Egerton <eggyal@gmail.com> wrote:

> I have a couple of questions about two of the four stated primary use
> cases:
>
> > The provisioning and use of keys within Web applications can be used for
> > scenarios like increasing the security of user authentication and
> determining
> > whether a particular device is authenticated for particular services.
>
> So, for example: server requests that the client sign a challenge,
> then verifies the resulting signature against known public key?
>
> Whilst such a layer of security is an improvement over the status quo,
> it does not address attacks during key provisioning: for example, on
> generating the keypair the public key is transmitted to the server,
> during which time malicious client-side script could substitute it for
> that of an attacker.  How does the server trust that the key it
> receives is indeed that of the user?
>
> One solution might be an API call to transmit specified public keys in
> a dedicated HTTP header.
>

The general security of key provisioning is a complex, often
vendor-specific solution (eg: GlobalPlatform, KeyGen2, etc).

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.

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


>
> > "On-the-fly" encryption of user communication can provide a further
> layer of
> > confidentiality besides simply depending on TLS, such as in Web
> > applications for instant messaging.
>
> So, for example: secure user-to-user communication through an untrusted
> webapp?
>
> If the webapp is untrusted then so too must be its client-side code;
> therefore there must be assurance that such code cannot access
> plaintext messages at either end of the communication.
>
> For example, the sender's browser could present a UI (that cannot be
> imitated by a webapp) for entry of plaintext messages and guarantee
> that only the ciphertext will be made available to the webapp's
> client-side code (perhaps form input elements could be modified
> through the DOM or with HTML attributes so that they trigger signing
> and/or encryption of their content prior to transmission and prevent
> scripting access to unsigned/unencrypted data; the browser would then
> only need provide some feedback that the element with focus is so
> secured).  Similarly, the receiver's browser must handle decrypted
> messages in a realm that is inaccessible to the webapp's client-side
> code.
>
> Are such threats in-scope for this project?  I noticed a related point
> was made in the thread on Netflix use case, but it didn't appear to be
> picked up—perhaps it has already been addressed elsewhere?
>
> -- Alan
>
>
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.

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)

Cheers,
Ryan