Re: Javascript integrity concerns

Thanks for the comments bence - response inline.

On Thu, May 16, 2013 at 5:05 PM,  <> wrote:
> Dear Members of Web Crypto API Team!
> Firstly I am really pleased to read about the great achievements done by the
> Web Crypto API team, because it has the potential to eliminate most of the
> wide spread concerns with browser based cryptography. Also I really looking
> forward to the implementations in browsers.
> However, as an amateur web developer I think there is one important weakness
> of this API, that is as follows. Several "weekend developers" - for example
> me - will start to use this API serving their javascript code from cheap,
> shared hosts. Even if they provide a web application with a secure
> connection (https), they can not guarantee that the integrity of the served
> javascript files is not compromised by curious employees of the hosting
> provider, or attackers who gain access to these loosely protected servers.
> In the meantime the above mentioned developers - not knowing these problems
> - would advertise their web application as super secure and they may claim
> that "customers can provide their most confidential data without the risk of
> abuse". If users do provide their confidential data curious employees and
> attackers may feel much temptation to simply modify the javascript code and
> gain access to the raw unencrypted data.

(Un)fortunately, we cannot prevent people from making false claims.
That's the nature of human conversation since time immemorial. Plenty
of sites still claim that XOR/ROT-13 is a "security solution", or
their "clever" schemes of AES-ECB with a CRC32 = cryptographically

It's a non-goal to prevent the false claims, but it is a goal to
enable real claims to be made, and the current API does permit a
number of strong applications to be developed in a space that they
cannot be today.

> So I think there should be some signature method to guarantee the integrity
> of the javascript code, in the sense that the script downloaded by the
> browser is the same as the one which was written by the developer, and not
> the one on the host, because the latter may be broken.

That signature method already exists. It's called HTTPS. It can
further be enhanced with CSP and certificate pinning.

If you don't trust your host, you have more fundamental problems.

While the naieve response would be to suggest that the problem you're
describing is addressable with "signed scripts" (something Netscape -
note, pre-Mozilla Co/Fo - had attempted), the reality is that it's
much more complicated than that. Simply delivering signed scripts
wouldn't be enough - since an attacker would simply strip off any
signed scripts and replace them with unsigned scripts, particularly if
they have physical access to the server.

Instead, you're problem space would (minimally) also need some form of
key continuity scheme, such that clients that received signed scripts
would continue to expect signed scripts. This would be the conceptual
equivalent of perfect forward secrecy for TLS - even after the
compromise of the key (or, in this case, the server), *existing*
sessions would still be protected.

While crypto would almost certainly be involved in such a discussion,
I would suggest it's a much better conceptual match to the work of the
WebAppSec WG, since the model of the threat and attack really have
less to do with cryptography than they do with a hostile server.

> I was thinking about this problem for a long while, and concluded that it
> can not be solved without integrating a sanity check into the browser (or
> into a plugin, which could be much more cumbersome).
> However, I might be wrong, as I am only a weekend developer, and also I am
> not sure whether this issue stays in the scope of Web Crypto API. Also there
> may be as much as a thousand letters in the public mail archive which I did
> not read through, so I am sorry if this is an already known or solved
> problem, or a duplicate of an existing issue.
> Best regards,
> Bence Ágg

There has been some discussion in WebAppSec regarding "script
signature validation" or hash validation of some kind, so I suspect
you'd find a receptive audience there. No guarantees, however.

This WG primarily focuses on APIs that enable the use of cryptography
once you have bootstrapped your 'secure environment' (eg: via HTTPS,
CSP, some-future-web-security-method, etc). This allows you to
continue operating securely - and to enable more robust applications.


Received on Friday, 17 May 2013 17:33:54 UTC