Code security question

mawdryn

Hi everyone,

I've been working on a multi-user, multi-access-level admin system for my database driven web sites, and I'm concerned about security holes within my code.

I'm pretty sure I've addressed the obvious stuff, such as one way encrypted passwords (md5) and input validation on all $POST and $GET variables to prevent code execution and sql injection.

I'm a bit new to sessions though, which is my major point of concern. The articles I've read so far are a bit confusing, but I've taken their advice by using session_regenerate(), ensuring that sessions have a timeout and re-validating passwords for extra sensitive functions such as user/password changes.

I don't use cookies, so I don't worry about that.

The multi-user design of this system means that I can't use .htaccess password protection?? (Correct me if I'm wrong)

Have I got any of this wrong and are there any other things I should be on the lookout for? Are there any good sites or Linux programs to test for php code vulnerability?

I would greatly appreciate any advice to help put my mind at ease.

knowj

I am currently building (this very moment) the same functionality for an e-commerce system I am writing.

The way I am going about things is when a user logs in a random md5 hash and the users IP address are stored within the database. The Hash is then stored within the users session.

When the user enters each page it will check their IP against the database and then check the hash matches the session.

I am about to make a post about this as I think their are flaws within my plan.

On another note make sure you salt your MD5 hashes
http://en.wikipedia.org/wiki/Salt_(cryptography)

laserlight

I'm pretty sure I've addressed the obvious stuff, such as one way encrypted passwords (md5) and input validation on all $POST and $GET variables to prevent code execution and sql injection.

Note that encrypting (or more typically, taking a cryptographic hash of) passwords for storage does not increase security, but provides a good failsafe for your users in the event that your database is compromised. The real security comes from using SSL/TLS so as to avoid sending passwords and other sensitive data in the clear over the Internet.

Consequently, a simple MD5 hash for password storage is not good enough. As an absolute minimum you need a salt (read Password Hashing), but you might want to consider more sophisticated techniques as well.

I don't use cookies, so I don't worry about that.

Then what do you use to store the session ids on the clientside? The typical alternatives (using the query string or hidden form fields) are worse.

The multi-user design of this system means that I can't use .htaccess password protection?? (Correct me if I'm wrong)

You can use .htaccess password protection for multiple user accounts, but it is probably more clumsy than using a web form-based authentication system with a database, especially since the "multi-access-level" part may be a problem with .htaccess.

The way I am going about things is when a user logs in a random md5 hash and the users IP address are stored within the database. The Hash is then stored within the users session.

When the user enters each page it will check their IP against the database and then check the hash matches the session.

The hash does not make sense since it duplicates the effort done for the session id. You would have two things to keep track of, instead of one, and if an attacker can get one of them, he probably can get the other. The problem with checking IP addresses is that they can legitimately change.

mawdryn

Then what do you use to store the session ids on the clientside? The typical alternatives (using the query string or hidden form fields) are worse.

Sorry, I'm confused about this, as I don't specify anything in my php code about cookies. Does php use cookies to store session data transparently? I definitely don't store session ids in GET or POST.

Consequently, a simple MD5 hash for password storage is not good enough. As an absolute minimum you need a salt (read Password Hashing), but you might want to consider more sophisticated techniques as well.

If I use the crypt() function, would any extra php/apache modules need to be installed?

The real security comes from using SSL/TLS so as to avoid sending passwords and other sensitive data in the clear over the Internet.

The cost factor is a concern for me. My main focus presently is to ensure the code itself isn't vulnerable and that I've taken all coding steps to ensure it wouldn't take a cracker 10 seconds to split open my sites without even having to bother about passwords.

knowj

PHP stores the SID in a cookie unless it is disabled on the server. The SID just references to an ID on the server.

I am yet to look into the crypt function but an MD5 hash with a salt is more than sufficient unless your dealing with valuable information (banks, card details etc...)

halojoy

knowj wrote:
PHP stores the SID in a cookie unless it is disabled on the server. The SID just references to an ID on the server.

I am yet to look into the crypt function but an MD5 hash with a salt is more than sufficient unless your dealing with valuable information (banks, card details etc...)

I have studied and benchmarked timings and implemented [man]mcrypt/man
One hookup is, that this is a php module that Hostings have to enable.
It is not standard in PHP, yet ....
I have chosen to use MCRYPT_CAST_128 cipher algorithm.
It is fast and safe enough. There are governements that approve use of c128.
It encrypts/decrypts like 25MB/sec on my development machine.

Have you tested my online service, for c128 encrypt any file ???
And then you can decrypt again .. if you remember your 16 chars password for your file 😃

My site is currently at freehostia.com .. they have PHP 5.0.5 with mcrypt() support.
Try link in my signature, if you are interested >>> Go to visit ... now!
Regards

mawdryn

Thanks everyone for the suggestions,

So tip #1 here is to strengthen the encryption on the passwords. I'll do so asap. I've since read quite a few articles on this subject and now my head hurts 🙁

I'm also going to do some more reading on php sessions.

Thanks again.

mawdryn

Hi again,

I've been reading and thinking and thus taking headache tablets 😛

I understand that session hijacking is a very difficult and lengthy subject.
What is the likelihood of the following scenario succeeding? (no ssl)

taking into account that I know nothing about security implications regarding session variables and cookies other than what I've read today....

1) user logs onto restricted area of site.
2) random string is generated and written into a session variable (and regenerated when user has to re-log in).
3) same random string is also written into a cookie (cookies must be enabled of course)
4) when any restricted page within the site is requested, the value in the session variable is compared to the value in the cookie and access is granted if they match. If not, user is prompted to log in again.

any thoughts appreciated.

laserlight

So tip #1 here is to strengthen the encryption on the passwords. I'll do so asap. I've since read quite a few articles on this subject and now my head hurts

I would not say that it is tip #1 as it does not increase security; security is typically a matter of the weakest link, not the strongest link, anyway.

Also, I hope you are not blindly taking halojoy's advice. The suggestion of mcrypt and CAST-128 is good (though AES, or an AES finalist like Serpent or Twofish, may be preferable these days), but not necessarily applicable in this context since you only need to use a cryptographic hash algorithm, not an encryption algorithm (though technically you can use one to implement the other).

If you use such encryption, you have to figure out where to store the encryption keys. The whole point of this server side encryption is to protect your users' passwords in the event the database is compromised... so storing the keys in the database would be completely useless.

What is the likelihood of the following scenario succeeding? (no ssl)

Replace "random string" with "session id" and you basically get how sessions work, though of course the value is not saved in a session variable, but on the server's filesystem and the user's cookie, and you may want to have a session variable that determines the access level and grant access accordingly. Since SSL is not used, it is susceptible to hijacking by an attacker sniffing the network.