W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2014

Re: [whatwg] Proposal: Specify SHA512 hash of JavaScript files in <script> tag

From: Igor Minar <iminar@google.com>
Date: Tue, 4 Feb 2014 17:08:12 -0800
Message-ID: <CAO9zZYPynTJf6Q1W4OySLCo7vRRNKOLEKCQuMm+usOK+UmHBnQ@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Some Developer <someukdeveloper@gmail.com>, whatwg <whatwg@whatwg.org>
I like this a lot!

I've been in discussions in the past where developers expressed concerns
about inability to verify that the bits delivered from CDN were the same
bits as the ones they reviewed and tested against during development.

It's very common to pull popular libraries (like jquery, angular,
underscore, bootstrap, etc) from a CDN, while delivering the html, css and
app specific bits from a different server. In this scenario the developer
has to blindly trust the CDN provider to disallow any kind of modification
of the bits.

>From what I read this is the reason why financial and healthcare apps can't
use 3rd party CDNs at all.

\i




On Tue, Feb 4, 2014 at 3:59 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Sat, 14 Dec 2013, Some Developer wrote:
> >
> > Currently most people store their JavaScript code on a CDN of some sort.
> > This often involves uploading their JavaScript files to a server hosted
> > and run by a third party which means the control and security of the
> > server is out of the hands of the website owner. If the CDN is hacked or
> > a rogue employee decides to edit your JavaScript you might end up
> > serving malicious JavaScript to your users without even knowing it.
> >
> > In order to overcome this problem I propose that a new attribute is
> > added to the <script> tag which allows the website owner to specify a
> > SHA512 hash of the JavaScript file ahead of time. If when the file is
> > downloaded from the CDN by the browser it does not match the SHA512 hash
> > in the HTML the browser should discard the JavaScript file and display a
> > warning to the user that the file has been modified and that it should
> > be considered as malicious.
>
> How common is this problem? Are there really sufficiently large numbers of
> people who use trusted computers to serve one part of their application,
> but use comparatively untrusted computers to serve subresources, to
> warrant such a feature? Presumably, anyone using shared hosting or a colo
> with a private server would be no more able to trust their primary server
> as their CDN. (Or equivalently, they'd be no less able to trust their CDN
> than their primary server.)
>
> Does anyone do this manually today? It would be relatively straight-
> forward to use CORS-enabled XHR to obtain the remote script, and then
> check the hash manually using script obtained from the primary server, and
> only eval the script if it matched. If nobody is doing this today, this
> probably indicates it's not a high priority for the platform. On the other
> hand, if people _are_ doing this, then that's a good indication that we
> should add it.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
Received on Wednesday, 5 February 2014 01:08:57 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:15 UTC