Topic awaiting preservation: PHP Sessions with Sensitive Information (Page 1 of 1)

I am attempting to allow for a user to remain logged into a content management system I am creating using PHP but am having some trouble coming up with a method of securing the session data. You can read this in two ways simple guide to preform a simple system hack, or to offer your advice on alternate solutions.

With this there are a number of issues that might be of use. I am operating on a shared server which I do not own or administer, and I am unable to have the administrator modify any of the server components (i.e. excellent non-standard encryption package X will not be installed). I am looking for pretty good security that will stop the script kiddies, I am sure that a good hacker could hack a session no matter what I do. I am also not able to require the users to have support for cookies. It should be noted that this is preventing a lose of data that will ultimately be backed up, and it will offer no easy method of gaining root though comprimising this system.

Where I am now is that I have a user table in a MySQL database, and I access this information to return the user's id for use in preserving the session.

Below is a truncated psuedo-php code for storing the session data.

$sql = SELECT id FROM table WHERE username = '$username' AND password = '$password';

$result = @mysq_query($sql);

$row = @mysql_fetch_array($result);

session_start();

$_SESSION['login_user_id'] = $row['id'];

header("location: mainCMSpage.php");

now with that code I am storing the user's id into the variable $login_user_id and I would check that the user is logged in using a simple function

session_start();

if(!isset($_SESSION['login_user_id']){

header("location:loginPage.php");

}

This works togeather well and good. The authentication script works well, I get the ability to traverse the pages without needing to worry about storing my login values in hidden fields or of the like (which require a post request to authenticate correctly).

With the session I have the problem of being able to do something like type into the browser http://site.com/mainCMSpage.php?login_user_id=1 and bam I am the CMS administrator. The security of the above site rests on the idea that an attacker will not know both the variable name and a valid input for the user.

This is a decent amount of security unless a user somehow releases their 'GET' information via a referal URL or another method of simple social engineering.

This is a decent level of security since a couple of pieces of information must come togeather, but for some reason I feel that there is a good posability of comprimise and possible lose of data associated with this, and it will take time to rebuild the data even with backups.

So, after all of this it comes down to a the simple question, is there a better method. I was considering using some sort of encryption, but I am not sure exactly how to work the encryption in this sense as it is all very open. If you do know of a better solution to this problem could you maybe supply me with a link to some implementation details or a tutorial? I have read bits and pieces on using the IP address for validation or to use a generated key, but I am unsure as to how this would be implimented and have not found anything to point out how it would work in code.

Let me know if you have anything!

Thanks a lot,
-Dan-

come in again, warmage:

why would http://site.com/mainCMSpage.php?login_user_id=1 lead to $_SESSION['login_user_id'] being set?

anyhow, if this is your primary concern, and you're on an apache, you can probably turn the auto-globals of (then you'll always have to go though $_GET

why would http://site.com/mainCMSpage.php?login_user_id=1 lead to $_SESSION['login_user_id'] being set?

This happens because using PHP sessions is also done by encoding the data into the url. I will look into turning off the auto-globals.

I like the MySQL trick as well.

-Dan-

[This message has been edited by WarMage (edited 11-29-2003).]

I feel you're having a missbelief here, WarMage:

PHP Session Data is *never* stored via URL. It is always stored somewhere on the server (possibly in the world readable /tmp directiory, though you can replace it with a php script to store somewhere else).

What is passed via the URL is the session id, ie. the key the server needs to find the data it stored for this session. This is also what would be stored in a cookie, if cookies are enabled.

Therefore, the scheme I proposed is actually pretty much what the server does.

You could add security by storing the remote ip within the session, and comparing that to the current one when the session is restored. This will execlude people behind multiple-server proxies, though, and won't help against attackers coming through the same proxy.

Why no cookies?

The biggest security flaw with sessions is that the id appears in the URL. If you use cookies then the only way a hacker can hijack a session is if they get the user to visit a page where the hacker can use javascript and read the cookie data within the same browser session that the user logged in. Unless you want the session cookie to hang around after the browser session ends, which is a bad mistake.

Seeing as this is an CMS I don't see why you need to aim for cookie less session support.

That said, if you must avoid cookies then I second TP's suggestion about validating the session data against the users IP (or some other kind of static yet relativly unique information you can obtain from the user's browser). And if you are storing passwords of any kind, always store them in a one way encrypted format (the PHP MD5() function is one possible solution) so if a hacker does gain access to your DB then all they get is a jumble of characters. To validate against an encrypted password stored in your DB just run MD5() on the input form the password field before you do the comparasion for the login process.

And in regards to the referal URL problem, if PHP is set up with the session.use_trans_sid = "1" (you can set this using the ini_set() function, although it's usually enabled by default) then PHP will automatically add in the session ID to URL's if the user doesn't support cookies (or if you've disabled cookies for sessions), and it will only add it to internal links, not links to external domains so the session ID shouldn't crop up in anyone's referal logs.

TP: I'm curious about the mention of a randomised key to be used for storing the session data in a database, how exactly would that work? (I realise that sessions can be handled with a database, just cursios about where and how the 'key' bit works into the fold)

Well, it was the first solution that made me feel much more secure. I was under the impression that Register_Globals was off, but I believe they(the server admin) must have turned it back during some previous update. Once I disabled it via .htaccess everything seemed pretty good.

I did mention a whole lot of issues against cookies. The reason I do this is that I have to make sure that the site is very accessable, as that is part of the job. If a user comes in with cookies disabled the server must be able to pick up the slack or I have angry customers.

Thanks for the help!

-Dan-