3

We know browsers disallow active mixed content in pages served using HTTPS. This is because the JavaScript could be modified by an active MitM which would compromise the security of the page. Many browsers will also block images/other passive content from being loaded from an insecure source for a number of reasons.

Why then, is it possible for a site served over HTTPS to redirect to a HTTP URL with a Content-Disposition: attachment or Content-Type: binary/octet-stream header that forces a download?

For example this download page is served initially over HTTPS but redirects the user to an insecure download URL. Chrome just blindly automatically downloads the file and presents no information as to its origin. Firefox does show the origin in its download dialog but still allows the download to proceed and doesn't warn the user at all:

Firefox does it right and shows the origin of the download

Given that a user downloading and running arbitrary code like this (that they believe to be from a secure site) can do much more damage than some injected JavaScript, why do browsers permit this behaviour? Why aren't these downloads forced to be served in a secure manner like included scripts?

Community
  • 1
Adam Williams
  • 363
  • 2
  • 8

1 Answers1

1

It's about respecting user's choice. Generally, you want to give the user choice to decide what they want to do.

Downloaded applications are inert. Just because you downloaded a virus doesn't immediately harm the system until you run it.

In any case, with applications downloaded from the internet, the user will be asked by the OS whether they want to allow running the application. In Windows, a prompt window appears, in Linux, you'd have to set the execute permission. Also, antivirus applications would scan downloaded applications they're being written/read. There's little need for the browser to prompt the user for this.

Windows also support cryptographic signature that can be used by security conscious users to prove the integrity of the downloaded application. In Linux, this is done by the package manager.

Why does this not apply for JavaScript? Well, generally users don't choose to run individual JavaScript files, but rather they are a side effect of visiting a site. And with JavaScript from unencrypted source, it's trivial for a MITM attacker to modify the script without the user knowing it.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • 1
    You have some interesting thoughts, but I feel like you miss the point I'm trying to make. "Generally, you want to give the user choice to decide what they want to do." - the user **cannot** make an informed choice in this scenario. To them, they are safely downloading the file over TLS (and unless they're running wireshark filtering on port 80 they won't know otherwise in Chrome because the UI does not indicate otherwise!) - which itself will ensure the integrity (w/ MAC) and confidentiality of the download. A securely published hash/pubkey could be checked, but TLS makes this less important. – Adam Williams Dec 20 '16 at 11:12
  • 1
    @AdamWilliams: Part of the reason is probably because Browsers have been trying to avoid having too many warnings/prompts, as that can desensitize the user to actual warnings. With application downloads, a rogue origin is probably more common than injecting a malware on the fly, so security conscious users have always checked signatures of downloaded applications. This is slowly changing though, as in the next year, both Firefox and Chrome have committed to slowly marking any pages not served in TLS as insecure, with the eventual goal of phasing out unencrypted HTTP. – Lie Ryan Dec 20 '16 at 15:01