In security, one of the most old and famous attacks is Man In The Middle attack. With this technique we can read all the packets the user is sending to a server and analyse it. The solution? Use a secure layer to encrypt all the traffic.
This, for web sites, require that the user browser use the HTTPS protocol. This relay in the authenticity of the server certificate and the trust relation between the browser and the certificate authority. It can be broken, but is not the point of this post, maybe for other one 🙂
If a website mix secure (HTTPS) and insecure (HTTP) content in the same page an attacker sniffing the net will be able to see, for example, our session cookie in clear text. This is a big risk if the attacker has control over the web content we are browsing (using a stored XSS attack) and insert some insecure reference on it to catch our cookie session.
I create a secure web page which load different (mixed) content. Using Wireshark to look the request my browser is doing I can determine that IE8 is currently making the request and, if the user decide to “block” it, only hide it.
This can make the user think he is safe when the request (and his cookie sessions) has been sended in clear text.
The other browser I tested is Firefox. When Firefox detect mixed content it load it and show an alert to the user to warn him about it. This is the same insecure process that Internet Explorer, but in this case the webpage is render normally so the user doesn’t have the false security feeling when the images are blocked by IE.
I, a huge fan of Firefox and the possibility to expand it using addons, have created a Greasemonkey
script to try to prevent this insecure behaviour of Firefox. It’s called Mixed Content Protection
and can be installed from the userscripts community web page. It requires Greasemonkey to work.
The script is very simple. It works only when we are accessing to HTTPS web pages and search for all the insecure references* in the HTML source code. It executes before the page loads, so it can change “on-the-fly” all these insecure references for the secure ones. If the secure object is not accessible it will not be loaded using a insecure protocol.
Currently it search for:
- All src attributes: img, iframe, object, script, etc.
- The href attribute of link tags for css files
- The insecure value in the param tag to the movie resource.
I think with these references it will cover mostly of the cases but, if you know any other resource can be loaded insecurely, please, feel free to comment me. Also it can fail in some cases, if you detect any issue please let me know 🙂
Thanks to Chema Alonso for draw my attention[Spanish blog, sorry] to this web browsers issue.