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

Threats to primary use cases from malicious client-side scripts

From: Alan Egerton <eggyal@gmail.com>
Date: Thu, 14 Jun 2012 13:40:27 +0100
Message-ID: <CA+phaeea=e-xBvnxxorjqnVsZ+JfNUgKaz5E0XnsZc79e+R=ng@mail.gmail.com>
To: public-webcrypto-comments@w3.org
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.

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

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
Received on Thursday, 14 June 2012 12:41:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:48 UTC