Incorrect implementation of HTTPS in the login page
If you had asked me a few years ago about how should a website owner protect a login page, I'd probably have said that they should make sure credentials are never sent over unencrpted channel. Now thanks to a little more knowledge and a few 'duh' moments I've come to realize that there is one another aspect of login page which goes un-noticed.
While most websites today do enforce that credentials are sent over HTTPS, they do not verify that the login page itself is not in the clear. In fact many of them have a "login/password" form in the clean on many unencrypted pages. For those who understand the risk of javascript injection can tell you as a matter of fact that the forms can be modified by a MiTM (man in the middle) device to do lots of interesting things... including, sending your password to an attackers server. Hence getting the password over encrypted channel wouldn't protect much.
A key point to note here is that this requires an active attack on the user instead of just being a passive listenner, but thats something which has become only easier over time.
While most websites today do enforce that credentials are sent over HTTPS, they do not verify that the login page itself is not in the clear. In fact many of them have a "login/password" form in the clean on many unencrypted pages. For those who understand the risk of javascript injection can tell you as a matter of fact that the forms can be modified by a MiTM (man in the middle) device to do lots of interesting things... including, sending your password to an attackers server. Hence getting the password over encrypted channel wouldn't protect much.
A key point to note here is that this requires an active attack on the user instead of just being a passive listenner, but thats something which has become only easier over time.
Comments