3 ms·

How would this protect you against a malicious server?

by sdevlin 13y ago

tghw 13y ago
If the server serving the HTML is pwnd, then it doesn't, but it doesn't really matter then, either. This protects against any external scripts being unexpectedly modified, e.g. someone MITM your jquery source.
- sdevlin 13y ago
  I guess that's true, but in practice XSS is a much bigger threat to your application than someone MITM'ing an HTTPS connection to Google's (or whomever's) CDN.
- sneak 13y ago
  If you don't allow external scripts to be modified, why host them externally at all? Why not just wget them and host them locally alongside the checksum document and skip all this silliness? Oh, also, those scripts can themselves load in other scripts you haven't checksummed. This is madness you're suggesting.
  - martin-adams 13y ago
    >> Why not just wget them and host them locally Because you might be using a CDN for performance and bandwidth benefits. If you relying on a third party piece of code that you allow to change at any time, then it is very difficult to do any release testing to give you a known set of conditions your application should work under.
  - tghw 13y ago
    In what scenario do you want external scripts to be modified? Why not take advantage of their ability to serve the scripts while also verifying that they are the same scripts you expected to have? You can also verify that those scripts do not load any other scripts in the version you have. Then, if it's changed later to load more scripts, you'll know about it. How is checking the validity of the scripts that run on your site madness??
    - rictic 13y ago
      It's... kinda madness. Just to be clear that we're talking about the same thing, here's the proposed process as I understand it: 1) load your loader script, which has the URLs, fingerprints of the scripts you want to run, and the necessary dependency information (jquery-ui must load after jquery for example). In the best case, this file is being served out by the same server that's hosting the HTML, that way at least you're not adding more attack vectors. 2) from the loader script, initiate ajax requests for each of the remote files you need 3) as you get each one back, validate that its signature matches those that are expected, raise an exception if it does not (ideally also displaying something to the user), and evaluating it if its signature matches and we've loaded all of its dependencies. So, why is this madness? 1) Most of the time the reason that you're letting a third party host these files is for speed. They've got a CDN, and hopefully the file will already be cached by your user. Grabbing resources with javascript that you could load directly in the html will slow down your page's loading time, as the browser's html parser isn't able to look ahead and fetch resources that are likely to be needed before the renderer has asked (HTML has a defined rendering order that can be kinda strict sometimes, this is the same reason why you don't put your <script> elements in the <head>). 2) Another reason for using a CDN for your JS libraries is convenience, which this process also wipes out. 3) The whole thing won't work at all unless the third party server sends back cooperative CORS headers, as you can't do an ajax request to a third party site without their cooperation. Finally though – and this is the big one – it's more convenient for the developers, strictly safer, and faster for the end user if you just compile all of the JS and serve from the same domain that's serving your HTML. As stated above, if that server is compromised, you're toast anyways (barring a browser extension or similar). If you really want some more security, look into SSL (and actually look into it, there's definitely much better and much worse ways of doing it).
      - tghw 13y ago
        Most of what you're describing as "madness" is already done in head.js and require. They have no particular speed penalties and handle dependencies better than just putting script tags in the right order. The one difference is that a system like this would check the hashes to verify the code. The one possible catch, as you mention, would be getting access to these scripts before they are loaded without having cross-origin problems. There are a number of problems with serving from your own domain. It is, in fact, much less convenient for developers, as it adds an extra step to the build process and requires the system to properly handle caching so that old resources are not still served after a build. It is also slower to serve from the same domain as there are connection limits. Lastly, it gives up all advantages of a CDN. My proposal is an attempt to continue taking advantage of CDNs and third party resources, but without giving them the keys to your site. Did you ever consider that Google has access to all of your users' cookies, if they wanted to add a small modification to jQuery or Analytics? Considering recent revelations about government involvement, is it really out of the question to believe that they never would take that information?

How would this protect you against a malicious server?

by sdevlin 13y ago

How would this protect you against a malicious server?

tghw 13y ago

If the server serving the HTML is pwnd, then it doesn't, but it doesn't really matter then, either. This protects against any external scripts being unexpectedly modified, e.g. someone MITM your jquery source.

sdevlin 13y ago
I guess that's true, but in practice XSS is a much bigger threat to your application than someone MITM'ing an HTTPS connection to Google's (or whomever's) CDN.
sneak 13y ago
If you don't allow external scripts to be modified, why host them externally at all? Why not just wget them and host them locally alongside the checksum document and skip all this silliness? Oh, also, those scripts can themselves load in other scripts you haven't checksummed. This is madness you're suggesting.
- martin-adams 13y ago
  >> Why not just wget them and host them locally Because you might be using a CDN for performance and bandwidth benefits. If you relying on a third party piece of code that you allow to change at any time, then it is very difficult to do any release testing to give you a known set of conditions your application should work under.
- tghw 13y ago
  In what scenario do you want external scripts to be modified? Why not take advantage of their ability to serve the scripts while also verifying that they are the same scripts you expected to have? You can also verify that those scripts do not load any other scripts in the version you have. Then, if it's changed later to load more scripts, you'll know about it. How is checking the validity of the scripts that run on your site madness??
  - rictic 13y ago
    It's... kinda madness. Just to be clear that we're talking about the same thing, here's the proposed process as I understand it: 1) load your loader script, which has the URLs, fingerprints of the scripts you want to run, and the necessary dependency information (jquery-ui must load after jquery for example). In the best case, this file is being served out by the same server that's hosting the HTML, that way at least you're not adding more attack vectors. 2) from the loader script, initiate ajax requests for each of the remote files you need 3) as you get each one back, validate that its signature matches those that are expected, raise an exception if it does not (ideally also displaying something to the user), and evaluating it if its signature matches and we've loaded all of its dependencies. So, why is this madness? 1) Most of the time the reason that you're letting a third party host these files is for speed. They've got a CDN, and hopefully the file will already be cached by your user. Grabbing resources with javascript that you could load directly in the html will slow down your page's loading time, as the browser's html parser isn't able to look ahead and fetch resources that are likely to be needed before the renderer has asked (HTML has a defined rendering order that can be kinda strict sometimes, this is the same reason why you don't put your <script> elements in the <head>). 2) Another reason for using a CDN for your JS libraries is convenience, which this process also wipes out. 3) The whole thing won't work at all unless the third party server sends back cooperative CORS headers, as you can't do an ajax request to a third party site without their cooperation. Finally though – and this is the big one – it's more convenient for the developers, strictly safer, and faster for the end user if you just compile all of the JS and serve from the same domain that's serving your HTML. As stated above, if that server is compromised, you're toast anyways (barring a browser extension or similar). If you really want some more security, look into SSL (and actually look into it, there's definitely much better and much worse ways of doing it).
    - tghw 13y ago
      Most of what you're describing as "madness" is already done in head.js and require. They have no particular speed penalties and handle dependencies better than just putting script tags in the right order. The one difference is that a system like this would check the hashes to verify the code. The one possible catch, as you mention, would be getting access to these scripts before they are loaded without having cross-origin problems. There are a number of problems with serving from your own domain. It is, in fact, much less convenient for developers, as it adds an extra step to the build process and requires the system to properly handle caching so that old resources are not still served after a build. It is also slower to serve from the same domain as there are connection limits. Lastly, it gives up all advantages of a CDN. My proposal is an attempt to continue taking advantage of CDNs and third party resources, but without giving them the keys to your site. Did you ever consider that Google has access to all of your users' cookies, if they wanted to add a small modification to jQuery or Analytics? Considering recent revelations about government involvement, is it really out of the question to believe that they never would take that information?