Re: Javascript integrity concerns

On Fri, May 17, 2013 at 10:33 AM, Ryan Sleevi <sleevi@google.com> wrote:

> Thanks for the comments bence - response inline.
>
> On Thu, May 16, 2013 at 5:05 PM,  <bence@suopte.com> 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
> protected.
>
> 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
> > http://suopte.com/en/
> > bence@suopte.com
>
> 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.
>

+1 to Ryans point above.

There is a possible WebCrypto angle, though. In the case where the UA has
verified the script in some way (whether HTTPS or some future script
signing mechanism), WebCrypto could offer the script the possibility to
obtain some attestation to this fact. ekr suggested a "signed-by-origin"
method in which signs a message provided by the script using a WebCrypto
key but also attaches, within the signed portion, the origin of the script
and the certificate chain that was used to verify it.

Like the extractable attribute and the key wrap/unwrap methods, this is
only useful if you have some reason to trust the UA and to believe that the
key being used is genuinely in the UA.

...Mark


>
> Cheers,
> Ryan
>
>