DevOps Zone is brought to you in partnership with:

Troy Hunt is a Software Architect and Microsoft MVP for Developer Security. He blogs regularly about security principles in software development at troyhunt.com and is the author of the OWASP Top 10 for .NET developers series and free eBook of the same name. Troy is also the creator of the recently released Automated Security Analyser for ASP.NET Websites at asafaweb.com. Troy is a DZone MVB and is not an employee of DZone and has posted 58 posts at DZone. You can read more from them at their website. View Full User Profile

Understanding the Risk of Mixed Content Warnings

06.12.2013
| 2248 views |
  • submit to reddit

Ever see one of these?

IE8 mixed content warning

Or these?

IE10 mixed content warning

Or maybe this one?

Chrome mixed content warning

It means something is wrong with the website – very wrong – yet somehow we seem to keep building websites that do this. The problem, as you’ll see in the video below, is that it jeopardises the security of traffic going backwards and forwards over what otherwise appears to be a secure site, at least in terms of implementing SSL. This can lead to issues such as the theft of identity data, potentially including such personal information as social security numbers. Fortunately there’s a channel to report potentially fraudulent activity except that, well, this video explains it best:

Of course it’s ironic that it’s the Social Security Administration that’s made a bit of a botch of this but it’s an all too familiar scenario. Tesco did itso did Versa Liftso did Top CashBack and a heap of others I haven’t previously written about. It’s rampant.

That’s the risk covered, let’s focus on the fixes and they’re all dead easy:

  1. Embed external content explicitly via the HTTPS scheme. If you’re only serving the page over HTTPS anyway then it ensures no slip ups.
  2. Use a protocol relative URL or in other words, embed resources such as the jQuery file in the example above as //ajax.googleapis.com/… Yes, I know it looks weird but it works and it means when the page is loaded over HTTP then the resource will be requested over HTTP. Load the page over HTTPS and the resource embeds over HTTPS.
  3. Test your damn web pages! No seriously, this is a fundamentally basic flaw and as soon as you load the page most browsers will start complaining. Have we – even us developers – become so desensitised to security warnings that we totally ignore them?!

For the curious, as I mention in the video this demonstration was achieved by mounting a man in the middle attack at the proxy level. I used Fiddler as the proxy and Fiddler Script to modify the jQuery file in the OnBeforeResponse event. Whilst all this occurred within my PC, it demonstrates the alibility for it to happen at a proxy server anywhere – or at the internet gateway of your local cafe, or elsewhere in the ISP, or via a wiretap on an enthernet cable or as I’ve shown recently with the Pineapple, via a rogue wireless access point the victim is connected to, possibly even without their knowledge.

Now as with my previous video on the risk of loading login forms over HTTP, many people will ask “Is this really a likely risk?” In fact that’s just the discussion I had with Rob Conery after the aforementioned post as even TekPubfollows this pattern. I look at it like this: you implement SSL primarily because you’re concerned about the risk of someone intercepting your traffic. Assuming you acknowledge – and attempt to protect against – this risk, you accept that all the HTTP components of the communication remain vulnerable ergo you need to protect against the SSL anti-patterns mentioned here.

Published at DZone with permission of Troy Hunt, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)