Re: [whatwg] Proposal: Specify SHA512 hash of JavaScript files in script tag
Sorry for the late response. Igor Minar, 2014-02-05 03:08 (Europe/Helsinki): 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 understand the problem and I have hit the same issue by myself. However, the suggested hash signature is far from enough. Most popular libraries have means to load additional files and plugins and the suggested hash is able to sign only the main file. If you cannot trust the CDN provider, you cannot trust that the rest of the files have not been modified. An attacker could use *any* file in the CDN network for an attack. If your signature cannot cover *all* files, adding the signature is wasted effort. There's no need to provide any additional tools for false sense of security. In addition, financial and healthcare apps may have to deal with rules set by local laws in addition stuff required by strict minimum for mathematically sound encryption. As a result, such apps may have to distribute copies of all the libraries by themselves in the future, too, regardless of any signature support for 3rd party distributed content. And if such app provider simply switched to SPDY, the service would highly probably work faster than the combination of plain HTTPS and CDN can provide. In the end, even if we had such a hash signature system (where authenticity of hash is provided by TLS of the main site), when it would be supported well enough to be trusted? 10 years has not been enough to get rid of MSIE 6.0... If you need security, the only real option is to serve content from servers that you can trust and use TLS to encrypt the traffic. -- Mikko
Re: [whatwg] Proposal: Specify SHA512 hash of JavaScript files in script tag
On 06/26/2014 01:18 AM, Mikko Rantalainen wrote: However, the suggested hash signature is far from enough. Most popular libraries have means to load additional files and plugins and the suggested hash is able to sign only the main file. If you cannot trust the CDN provider, you cannot trust that the rest of the files have not been modified. An attacker could use *any* file in the CDN network for an attack. If your signature cannot cover *all* files, adding the signature is wasted effort. There's no need to provide any additional tools for false sense of security. Couldn't the main file check any additional files it downloads, either by loading them via script tag with hash or by manually hashing them as they're downloaded (presumably easier once WebCrypto is adopted)?
Re: [whatwg] Proposal: Specify SHA512 hash of JavaScript files in script tag
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Specify SHA512 hash of JavaScript files in script tag
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 i...@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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Specify SHA512 hash of JavaScript files in script tag
On Sat, Dec 14, 2013 at 3:41 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * 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. You probably want to talk to http://www.w3.org/2011/webappsec/. -- Indeed, the webappsec WG is currently working on sub-resource integrity spec that covers exactly that use-case: https://rawgithub.com/w3c/webappsec/master/specs/subresourceintegrity/index.html
Re: [whatwg] Proposal: Specify SHA512 hash of JavaScript files in script tag
* 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. You probably want to talk to http://www.w3.org/2011/webappsec/. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
