Pete Freitag Pete Freitag

Web Form Security and the Middle Man

Updated on November 20, 2023
By Pete Freitag

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:
  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
  5. Bob enters his username and password, and submits his credentials unencrypted over the network.
  6. The attacker steals bob's credentials, 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.

Update: This type of attack is called a HTTPS stripping attack, and we now have Strict-Transport-Security to address this.

security forms https browsers

Web Form Security and the Middle Man was first published on May 17, 2006.

If you like reading about security, forms, https, or browsers then you might also like:

Weekly Security Advisories Email

Advisory Week is a new weekly email containing security advisories published by major software vendors (Adobe, Apple, Microsoft, etc).


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,
by Peter Bell on 06/08/2006 at 6:45:30 AM UTC
Ahh, good point Peter.
by Pete Freitag on 06/08/2006 at 9:55:06 AM UTC
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?
by Pete Freitag on 06/08/2006 at 10:00:50 AM UTC
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.

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.

Best Wishes,
by Peter Bell on 06/08/2006 at 10:23:38 AM UTC