One objection to using HTTPS for everything that I occasionally see is the loading of 3rd party scripts (facebook, ad networks, etc.). The premise of the argument against using HTTPS is that these 3rd party scripts are only accessible via HTTP, so users of old versions of IE would get scary popup warnings.
The other interesting item from this article was that you should always load resources via HTTPS, because a malicious script would have control over the DOM. It seems like there is a need for some facility in browsers to let pages delegate limited privileges to 3rd party scripts (maybe only able to read/write in a certain div or something?), so that users can still be confident that their connection is secure.
If you have third party scripts on your page, you've already given away control of your page. A compromise on the third party's servers makes your site vulnerable as well. The safe thing to do is to fetch third party content server-side, massage it and then pass it on to your front end.
Naturally, this requires more work, and you'd probably end up getting rate limited since all API requests now come from a single IP (your server's) rather than each user's IP.
Alternately, you can iframe third party scripts (or depending on privacy requirements, you may need to double-iframe them), but this means that the script cannot directly interact with content on your page.
Trade-offs everywhere, which is why the architect of your system really needs to know what he or she is doing.
It seems like there is a need for some facility in browsers to let pages delegate limited privileges to 3rd party scripts (maybe only able to read/write in a certain div or something?), so that users can still be confident that their connection is secure.
There is most definately such a need and here is one attempt to address it:
It's a subset of JavaScript that can be sandboxed within other JavaScript, implemented as a lexical sanitizer. It's a huge hack, but I can't think of a better way to do this with existing technology.
What we really need is a replacement for JavaScript.
The real problem with mixed content is that you're compromising the security of SSL when you allow insecure resources on the page. If a page is otherwise secure and includes an insecure ad script call, for instance, it's relatively easy to hijack that javascript request and munge it to do whatever you want with the DOM and javascript-accessible cookies.
Comments
One objection to using HTTPS for everything that I occasionally see is the loading of 3rd party scripts (facebook, ad networks, etc.). The premise of the argument against using HTTPS is that these 3rd party scripts are only accessible via HTTP, so users of old versions of IE would get scary popup warnings.
The other interesting item from this article was that you should always load resources via HTTPS, because a malicious script would have control over the DOM. It seems like there is a need for some facility in browsers to let pages delegate limited privileges to 3rd party scripts (maybe only able to read/write in a certain div or something?), so that users can still be confident that their connection is secure.
If you have third party scripts on your page, you've already given away control of your page. A compromise on the third party's servers makes your site vulnerable as well. The safe thing to do is to fetch third party content server-side, massage it and then pass it on to your front end.
Naturally, this requires more work, and you'd probably end up getting rate limited since all API requests now come from a single IP (your server's) rather than each user's IP.
Alternately, you can iframe third party scripts (or depending on privacy requirements, you may need to double-iframe them), but this means that the script cannot directly interact with content on your page.
Trade-offs everywhere, which is why the architect of your system really needs to know what he or she is doing.
It seems like there is a need for some facility in browsers to let pages delegate limited privileges to 3rd party scripts (maybe only able to read/write in a certain div or something?), so that users can still be confident that their connection is secure.
There is most definately such a need and here is one attempt to address it:
http://code.google.com/p/google-caja/
It's a subset of JavaScript that can be sandboxed within other JavaScript, implemented as a lexical sanitizer. It's a huge hack, but I can't think of a better way to do this with existing technology.
What we really need is a replacement for JavaScript.
The real problem with mixed content is that you're compromising the security of SSL when you allow insecure resources on the page. If a page is otherwise secure and includes an insecure ad script call, for instance, it's relatively easy to hijack that javascript request and munge it to do whatever you want with the DOM and javascript-accessible cookies.