Web Form Security and the Middle Man
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:
- 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.
- Bob is at the coffee shop and needs to check his bank account, so he types in: www.bobsbanking.com
- Bob's Banking server returns the bank homepage with a login form. The login form redirects to a secure HTTPS address.
- 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
- Bob enters his username and password, and submits his credentials unencrypted over the network.
- 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.
- Secure Forms - January 27, 2006
- HTTP Strict Transport Security - September 17, 2010
- Secure Browsing Mode - June 28, 2006
- How To Scream Unsecured - May 2, 2006
- Updating Java on ColdFusion or Lucee
- ColdFusion returning empty response with server-error: true
- Careful applying CF11u16, CF2016u8, CF2018u2
- Sessions don't work in Chrome but do in IE
- csrfVerifyToken does not invalidate the token
- The cf_sql_ is optional in cfqueryparam
- Cookie Expires / Max-Age 1969-12-31T23:59:59.000Z
- Burst Throttling on AWS API Gateway Explained