views:

280

answers:

4

I was looking at the livehttpheaders plugin for Firefox and decided to test my login page. I noticed that the parameters shown inside of it contain my login and password. For example:

username=sarmenhb&password=thepassword&submit=Login

in plain English.

I don not see this on other sites.

What can I be doing wrong? I see this as a security flaw. The login page, all it does is validate and log in the user. All fields are ran through mysql_real_escape_string (in case that is relevant).

+8  A: 

The information has to get to the server from the client some how. Use SSL if you are worried about security.

Even if you do an MD5 hash in Javascript, this does not help because it is trivial to submit the hash to the login page, and the hash effectively becomes the password. All things are plain text until they, or the transport, is encrypted. POST the variables, use SSL.

To add from my comment below. You may not see the headers for other-sites because they may use AJAX, POST method or another client-side mechanism to authenticate.

Aiden Bell
but when i run http live headers on another site why is it that i dont see the same information in plain english?
Maybe it uses AJAX to authenticate and grab the session cookie? Depends on the site.
Aiden Bell
While you can't just MD5 the password on the client side; the server can set a token and force the client to MD5(token + password). This makes the transmitted password hash different each time, and also acts like a salt stopping someone from looking up the password in a MD5->Plaintext database.Oh course, using SSL is the accepted fix.
Matthew
@Matthew, indeed.
Aiden Bell
A: 

When you are using http and submit a form, the form contents are sent across the wire "in the clear", as you're seeing. When that form submission includes credentials, then yes, you have a security issue.

Among your alternatives are:

  • Use https, so that over-the-wire communication is encrypted
  • Use OpenID for login, which pushes management of https credentials off onto the user's OpenID provider
  • Use Javascript on the client side to encrypt the credentials before posting the form

The latter approach tends to get people into trouble if they're not very careful, because the mechanism for encrypting the credentials is fully visible to anyone who cares to inspect the javascript.

Dave W. Smith
+1  A: 

This reminds me of a certain building in a large city (I am sure there are others in other places) where they have a web based interface to the building concierge. Residents can log on to a web site (over http) and specify (among other things) who is allowed to enter their apartment for repairs etc in their absence. I am sure the whole thing was programmed by someone's nephew who is a 'guru'.

I am sure it is, shall we say, good enough.

Sinan Ünür
+1  A: 

You're seeing it for your site and not for others because livehttpheaders shows the URL for GET requests, but doesn't show the content for POST requests.

Sending login information through GET requests is a minor extra security hole over sending them POST, in that the URLs for GET requests are often logged in various places, whereas almost no one logs POST content. Does everyone with permission to look at the webserver logs have permission to know the CEO's password?

However, as others have pointed out, unless you're using https: for login, data is going across the network in plain text whether you use GET or POST. This is almost always bad.

Still, as an intermediate measure I would change your app to send username and password stuff as a POST, not a GET, so that you don't end up storing usernames and passwords in your webserver logs - it's no use using https over the wire if you're doing something that then writes the username and password to an insufficiently protected logfile on the server.

Daniel Martin