Secure Web Password Fields + http to https redirect

Question

I'm a software developer but I'm marking my niche in secure development. It turns out that while using WebScarab, I discovered that a popular user group site doesn't appear to properly take care of web passwords: The login page is http, but the submit button links to an https link.

Using WebScarab I captured the password in plaintext form... meaning to my eyes, that my message will be sent as plaintext, unless WebScarab is looking at this input BEFORE it encapsulates it via https.

In any case, this makes me VERY uneasy staring at plaintext in the http request...

Are my worries founded here? What should be my next step? (I've already reported this to the vendor.)

Answer 1

@Hendrik is right to say that this is a security risk in that a non HTTPS login page may allow for an attacker to modify the submit link before the user clicks it, however to the point in your question around webscarab.

It (along with other proxies) does intercept HTTPS traffic (assuming that you've set it as a proxy for all protocols), so it doesn't necessarily mean that the traffic was going to traverse the Internet in the clear. If the post was to an HTTPS URL then it would be encrypted.

You can usually tell when using one of the intercepting proxies, as you'll get an SSL error message about the certificate not matching (unless you've setup the browser specifically to trust certs from the proxy)

Answer 2

Yes, this is a security issue because an attacker may be able to change the HTML code. He can change the action attribute of the form to point to his own server. Or less obvious and better: Add some javascript code that mirrors the password to his own server without breaking the login to the real site.

Unfortunately both Facebook and Twitter set a bad example here. Google Plus, however, redirects to https immediately, so there is some hope.

What should you do? Educate users that they need to check the address bar for https and the correct domain before they enter any private information into web forms.

Answer 3

Rory is exactly right, but I'd like to emphasize that you (and your users) should be extremely wary of broken SSL certificates. There are intercepting SSL proxies in the world that can read and modify anything you send, based on playing games with certificates that lead to exactly these errors.

If you habituate yourself, or worse, your users to accepting certificate errors, the security benefit of SSL essentially disappears in the face of absolutely anyone in the packet path (e.g., at the same coffe shop or in the same hotel, not to mention the IT department).

I know zero about webscarab, so forgive me if this is out of context, but you should always be suspicious whenever you see plaintext passwords in packet captures. If you're sending around plaintext passwords on your app's backend, you had better be very sure you understand the security properties of the network in question.

SSL is cheap and easy. Turn it on everywhere you possibly can and be happy.

Answer 4

I have not tried out webscarab yet, but I assume it intercept HTTPS traffic by generating unsigned https certificates. A http login page, where the submit for is pointing to a https resource, should be secure. You have probably accepted a webscarab ssl certificate in your previous debug sessions, and you would normally get a warning about it.

But, https is broken in many ways. In the case of https interception, generating new SSL certificates is not necessary at all! Why?

If the attacker is using an intercepting proxy (MiTM), they can cleverly rewrite all html links from https:// uri's to http://. Now your site is no longer using SSL to encrypt sensitive data, and the user will not receive any SSL certificate warnings, because they are not used!

sslstrip is a proxy which does exactly that.

A countermeasure for this could be to obfuscate your links in such way that sslstrip will not be able to rewrite your https links. Javascripts and CSS comes to mind.