Web Form Security and the Middle Man

May 17, 2006

secure form image A friend of mine, Matt Finn, was telling me about a security issue he realized recently. Although this issue is somewhat hard to exploit (you have to do a man in the middle type of attack) resolving it requires both web developers and end users to break bad habits, and web browsers to get a bit smarter.

Here's the notion of the attack:

  1. The attacker gains access to a router, or is able to route traffic through their machine. This could be a major internet router, or the wifi router at the local coffee shop.
  2. Bob is at the coffee shop and needs to check his bank account, so he types in: www.bobsbanking.com
  3. Bob's Banking server returns the bank homepage with a login form. The login form redirects to a secure HTTPS address.
  4. Before the response is sent to Bob's computer, the attacker changes the response such that the form action submits to the un-secured http://www.bobsbanking.com/login
  5. Bob enters his username and password, and submits his credentials unencrypted over the network.
  6. The attacker steals bob's credentails, and redirects him to the correct HTTPS address where bob can view his account, and has no idea that his account was just stolen.

The lesson for web developers

Don't put forms that ask for sensitive information on pages that are not secured. How are the users supposed to know that the form action is secure? Do you expect them to view source?

The lesson for web users

Don't EVER enter your sensitive information on a form that does not reside on a HTTPS page. You don't know if the contents of the page were modified in transit by a man in the middle.

How browsers can help

It is really not up to the browser to solve this problem, but they could make things a lot better by indicating that the form action is secure. This could be done by changing the icon as Chris Shiflett had suggested.

Related Entries

7 people found this page useful, what do you think?


Hello Pete, Just saw this post (belatedly). The problem is real, the solution is illusory. Unless you're running a SSH session, all you have to do is start by going to an unsecured web page. If the Man In The Middle (MITM) attacker is in place, your request for the page goes to them, they pull down the website and send it to you. Now you click on the "secure form link" to go to the sign up form. You request a secure connection and he provides you one between you and him while he goes and makes a secure connection with the bank. He gets the secure form from the bank (which is sent securely to HIM - not YOU), so he can open it.He then secures this and sends it to you so you get a "secured" form from him with the lock and everything. SSL doesn't provide security against MITM, so don't check your bank balance at Starbucks! Best Wishes, Peter
Ahh, good point Peter.
I was just thinking about this, and I'm not sure that it would work. The user would get a warning if he altered the contents of the secured page sent from the bank. When the user fills out the "secure form" the contents of the form would be encrypted, the only one who can decrypt it would be the bank , or tons of brute force. In order for that to work the hacker would need to use a different ssl certificate than the bank. And in this case the user would know because the browser would warn them, Correct?
Hi Pete, The first point is moot as the form is going from user to MITM and MITM to bank and back, so MITM is pretending to be the bank and doesn't need to brute force anything. The second point sounds convincing, however. I did some digging. It seems the user DOES indeed get an invalid certificate message, but enough just click continue anyway. That seems to be what it is posited on. FYI, here's a site that talks about doing this in more detail. http://www.oklol.co.uk/?p=33 That said, according to this posting, there is an IE specific attack using chained CA"s which might avoid the "invalid certificate", although it is an old posting, comes from a quick google search and I have not verified whether this is still (or even ever was) true. http://www.thoughtcrime.org/ie-ssl-chain.txt Best Wishes, Peter
I just tested that with our Thawte cert, and it doesn't validate on IE 6. However, as the posting says Thawte certs explicitly include the Basic Constraint CA=FALSE. Verisign certs do not include the Basic Constraint information, which is what causes IE to incorrectly pass the cert as valid. I don't have a Verisign cert to test it with though. I suppose the key here is if you are going to check your bank balance at a public location and you are paranoid, you should make sure the login page is https, and additionally click the lock button and make sure there's only one hop from your bank's cert to the trusted root cert. Btw, Safari and Firefox are fine, they both warn with an "Invalid certificate" dialog. Matt
why is it necessary to secure a webform from webbots?

Post a Comment


Spell Checker by Foundeo

Recent Entries


did you hack my cf?