How secure are sessions in php ?

[lazy_yogi]

Does anyone know how secure sessions are in php ?

Is it stored on the server ?
If so, can it be retrievec by a third party somehow?
If not, it must be stored on the client machine by PHP and encrypted I assume.

Info and links from anyone who has dealt with this would be appreciated

Cheers,
Eli

[drzoid]

All the variables you store in the context of a session are stored on the server and are referred to with the session id. This id is a unique string, which identifies the client and is transmitted at each request (either as cookie or within the GET/POST request data). Now if a malicious user can get hold of this id he/she can take over the session. Such a case can be prevented if you store additional user/connection specific data with the session (browser, ip address,....).

[Widow Maker]

Normally stored as a file, though I shouldn't think that session data is encoded automatically though ?

For passwords for example, use MD5. Also consider moving from files - default - to database.

If your unsure, I seen an article over at php:arch Tried to upload the PDF, but it was way too big.

[Phil.Roberts]

By default, PHP session data is stored as a serialized array in a plain text file which is stored in the server temp directory. This has a number of security hazards as this directory is accessible to all users on the server.

However it is possible to define a customer session data handler which can abstract the storage of the session info to a method of your choice.

[kaimeder]

php-sessions are vulnerable to fixation-attacks as outlined in
http://de2.php.net/manual/en/ref.session.php
-> http://www.acros.si/papers/session_fixation.pdf

kai

[Widow Maker]

Looking breifly through the PDF, very interesting

Learn something new everyday, need to read some more later but.

[HarryF]

It's possible to use PHP sessions in a secure manner, as far as anything on the web is secure. Here's a brain dump of issues to watch out for though;

1. Shared web servers - anyone else on the server can read your session files if PHP is running as an Apache module (so the session files belong to the web user). They (probably) won't know the site the sessions apply to but you may still be putting sensitive info (like credit card details) somewhere for all to see. Using a custom session handler to store the sessions in a database is probably the best solution. You might consider MySQL HEAP tables if performance is an issue (assuming MySQL running on same machine as Apache).

2. XSS exploits and session hijacking - using JavaScript users can be fooled into giving away their active session_id. All someone needs to "hijack" a session is the unique session id. Research XSS and how to prevent it. Accept that session hijacking cannot be entirely prevented (using IP address for example is foiled by AOL, who assign a new client IP on more or less every page request) and double check "critical actions" a user can perform e.g. changing password - require the old password (which the session hijacker should not know). Displaying credit card infomation - do like Amazon and only display the last four digits. Etc.

3. Session IDs in URL (and hijacking) - if you're using session IDs in the URL (as opposed to a session cookie), make sure offsite links do not contain the session ID (or the remote site will be able to hijack) - PHP should take care of this. Also your visitors may give away the session ID in the referrer field - ideally pass off site links through a redirect page, to elimate the referrer (although, unfortunately, some browsers keep the last 3 pages viewed I believe - unsure of facts). Ideally, don't pass session ids in the URL - require users to accept a cookie if they need to "log in".

4. Use SSL (HTTPS) - a session ID can be "sniffed" between the client and your server. If it's an app with money involved, SSL is a requirement. Otherwise you have to live with the risk.

5. Don't use cookies for store sensitive information. Not really about sessions but I've seen people implement session-like behaviour using cookies. Cookie data, unlike sessions, gets stored on the client site. Apart from the "sniffing risk", a large majority of Windows users have little idea of security and may be "owned by haxor". Otherwise, cookies (aside from session cookie PHP creates for you) are generally meant for long term (i.e. between visits) data persistance (e.g. "Remember Me") rather than "active session" persistance.

Brain empty for the time being.

[Widow Maker]

http://www.php-mag.net/itr/online_ar...odeid,114.html

Just something I've found a minute ago, there is a link also at the bottom leading to the HTTP1/1 standard which might be useful to you.

[naskovoto]

Hi guys,
reading these posts gave me another idea of session vulnerability. Maybe it is too obvious to you and that is why is not mentioned.
Anyway I thought it was a good idea to share it.

Imagine you work in a small web development company. You create websites using PHP and offer hosting on a server of your own. You are a small company that's why you can afford only one server. Your company is so small that if you don't reuse your code you will not finish your projects on time . You have created a beautiful PHP class for user login which you use on every website that you produce.
Not so hard to imagine is it? You don't store the username and password of the user that is logged. You keep the UserID instead because you think it is enough and you don't want to store usernames and passwords in a file which can be read from anyone with access to the server, and you save one database request of course. If the UserID session variable is set then the user is logged.

The question is:
What will happen if someone logs to one of your websites where the registration is free for example, and then use his session_id when going to another of your websites having paid registrations?

The session is there, the user is logged, the second website is hacked.
I hope this will have someones eyes open
And sorry if there is no way to have a programmer so stupid to fulfil all these factors

The simple and obvious solution is storing the HTTP_HOST in the session as well.

[dagfinn]

Your company is so small that if you don't reuse your code you will not finish your projects on time . You have created a beautiful PHP class for user login which you use on every website that you produce.

Is your scenario that the different sites or applications use the same login class but the user data is stored in different databases? In that case, you should be able to go from one application to another and find yourself logged in as a different user, because the user ID belongs to someone else.

If it's all in one database, then once you're registered on one site you should be able to simply go to the other site and log in as yourself. In that case, it has nothing to do with sessions, it's just a lack of adequately fine-grained access control.

[el8]

To reduce a chance of session hijacking you can generate fingerprint for each session ID and store it somewhere (i.e. mmcache's shm, filesystem) and in session variable

You can generate fingerprint with md5 function:

$fingerprint = md5($_SERVER['HTTP_USER_AGENT'].@$_SERVER['HTTP_ACCEPT_CHARSET']."secretword".$username);

On each request you just compare session fingerprints.

I'm using mmcache shm feature to store fingerprints together with last access time so I can handle timeouts and view how many users are currently visiting my site.

Overhead is very little.

As someone earlier mentioned you can write custom session handler, or even use mmcache's session store feature (if you can install it on your box)

Cheers

[drzoid]

To reduce a chance of session hijacking you can generate fingerprint for each session ID and store it somewhere (i.e. mmcache's shm, filesystem) and in session variable

You can generate fingerprint with md5 function:

$fingerprint = md5($_SERVER['HTTP_USER_AGENT'].@$_SERVER['HTTP_ACCEPT_CHARSET']."secretword".$username);

On each request you just compare session fingerprints.

I'm using mmcache shm feature to store fingerprints together with last access time so I can handle timeouts and view how many users are currently visiting my site.

Overhead is very little.

As someone earlier mentioned you can write custom session handler, or even use mmcache's session store feature (if you can install it on your box)

Cheers

http://www.sitepoint.com/forums/showthread.php?t=157291

[el8]

huh, I have missed that article
Since I can install mmcache on my server i prefer using its shm feature instead of DB storage because its faster for my case since mysql server is on remote host.

[jcesar]

To secure a session look at the configuration file (or .htaccess)

session.use_cookies boolean
session.use_cookies specifies whether the module will use cookies to store the session id on the client side. Defaults to 1 (enabled).

session.use_only_cookies boolean
session.use_only_cookies specifies whether the module will only use cookies to store the session id on the client side. Defaults to 0 (disabled, for backward compatibility). Enabling this setting prevents attacks involved passing session ids in URLs. This setting was added in PHP 4.3.0.

session.referer_check string
session.referer_check contains the substring you want to check each HTTP Referer for. If the Referer was sent by the client and the substring was not found, the embedded session id will be marked as invalid. Defaults to the empty string.

[Andrew-J2000]

It's possible to use PHP sessions in a secure manner, as far as anything on the web is secure. Here's a brain dump of issues to watch out for though;

1. Shared web servers - anyone else on the server can read your session files if PHP is running as an Apache module (so the session files belong to the web user). They (probably) won't know the site the sessions apply to but you may still be putting sensitive info (like credit card details) somewhere for all to see. Using a custom session handler to store the sessions in a database is probably the best solution. You might consider MySQL HEAP tables if performance is an issue (assuming MySQL running on same machine as Apache).

2. XSS exploits and session hijacking - using JavaScript users can be fooled into giving away their active session_id. All someone needs to "hijack" a session is the unique session id. Research XSS and how to prevent it. Accept that session hijacking cannot be entirely prevented (using IP address for example is foiled by AOL, who assign a new client IP on more or less every page request) and double check "critical actions" a user can perform e.g. changing password - require the old password (which the session hijacker should not know). Displaying credit card infomation - do like Amazon and only display the last four digits. Etc.

3. Session IDs in URL (and hijacking) - if you're using session IDs in the URL (as opposed to a session cookie), make sure offsite links do not contain the session ID (or the remote site will be able to hijack) - PHP should take care of this. Also your visitors may give away the session ID in the referrer field - ideally pass off site links through a redirect page, to elimate the referrer (although, unfortunately, some browsers keep the last 3 pages viewed I believe - unsure of facts). Ideally, don't pass session ids in the URL - require users to accept a cookie if they need to "log in".

4. Use SSL (HTTPS) - a session ID can be "sniffed" between the client and your server. If it's an app with money involved, SSL is a requirement. Otherwise you have to live with the risk.

5. Don't use cookies for store sensitive information. Not really about sessions but I've seen people implement session-like behaviour using cookies. Cookie data, unlike sessions, gets stored on the client site. Apart from the "sniffing risk", a large majority of Windows users have little idea of security and may be "owned by haxor". Otherwise, cookies (aside from session cookie PHP creates for you) are generally meant for long term (i.e. between visits) data persistance (e.g. "Remember Me") rather than "active session" persistance.

Brain empty for the time being.

Security is always a compromise between performance.

• SQL Injection - [Resource] [example]
• Obscurity - [Resource]
  
  • If there are any flaws in the design of the security, or the server is compromised this could reveal and expose private data.
• Cookies - [Resource]
  
  • Sign Cookies over SSL as Secure.
  • Cookie Recipe [Resource]
    
    
    
    The recipe for our cookie follows easily from the hints presented in Section 3. We create an unforgeable authenticator that includes an explicit expiration time. We use HTTP state (i.e. cookies) to store this authenticator with the client. The value of this cookie is shown here:
    
    
    
    exp=t&data=s&digest=MAC(exp=t&data=s)
    
    Our cookie requires the use of a non-malleable MAC; that is, one where it is intractable to generate a valid ciphertext from a plaintext message related to a plaintext message with a known ciphertext [12, 24]. That is, no adversary can generate a valid ciphertext without both the server’s secret key and the plaintext, no matter how many samples of valid plaintext/ciphertext pairs the adversary has. Examples of keyed, non-malleable MACs are HMAC-MD5 and HMAC-SHA1.
    
• Encryption
  
  • This is usually where most security systems tend to fail. Usually allowing attackers to guess concatenated values by brute forcing the hash.

[whiterabbit]

How much time is needed for somebody to sniff and then to use that info to hijack a session?

I am confused on this whole thing but I have been playing with a system for our virtual store front. First off let me say it's just a userid and passwd that we send back and forth and the store front is only used for communications, ordering supplies, proofing etc. No dangerous info is exchanged.

Here is our scenario.
First off our customers are the only ones allowed in. We wanted a simple way to let them in so we created a flash swf movie and put a shortcut to it on their desk top. They basically enter their personal passwd and the swf then does some stuff.

1. Generates a random number
2. Uses that number to jumble up the passwd and userid hardcoded in the swf.
3. Send the info to the server along with the random number jumbled along with the info.
4. The server knows where to look for the random # and then how to uncode the jumbled info.
5. If okay a temp passwd good for 30 mins is generated and sent back to swf.
6. SWF then launches a browser window setting the userid and temppasswd which from then becomes the session passwd.

I was thinking of taking it a step further and having the jumbling continue changing the tempass for every new page but since I dont even know how hijacking takes place this might be stupid.

On the client side, the swf passowrd is entered using mouse clicks and I am looking for a way to get some computer info so its only good for that computer. I dont know what I should be looking for.

This is all probably futile anyway, but I am interested how would this type of scenario be hijacked. Could they sniff the session password and unjumble it in time to use it?

Thanks for your comments. If I have done something really stupid, it's because I keep reading how effective one solution is just to have someone else comment on it's vulnerability.

PS. I know the swf can be grabbed from somebody in the clients office but if they go to that extent let them have it.

[Widow Maker]

Wouldn't think that using a *SWF file to register a username/password would prevent a session hi-jacking - as you've found out, it's a server-side issue

As to how someone can actually hi-jack a session, have a good, long hard read of the page I posted earlier in this thread - explains (figure number 2) how a hi-jacking can be done, if you've not already read the article in question

[Andrew-J2000]

Wouldn't think that using a *SWF file to register a username/password would prevent a session hi-jacking - as you've found out, it's a server-side issue

As to how someone can actually hi-jack a session, have a good, long hard read of the page I posted earlier in this thread - explains (figure number 2) how a hi-jacking can be done, if you've not already read the article in question

Exactly...

Firstly it does not matter how you connect the client to the server (or vice versa), whether this is using 'SWF', an Application, or browser. Regardless, of the medium used, never trust the client. Do not cache username/passwords or any private data on the client.

How much time is needed for somebody to sniff and then to use that info to hijack a session?

In order to hack a web-server generally 'foot-printing' the server to determine exploits or vulnerabilities occur somewhere along the line. After foot-printing a server and determining a vulnerability, a simple program can be created to automate, processes. Whether this be session hi-jacking or any other form. So the answer to your questions, is seconds. Note: you do not even need a program to automate this...

Uses that number to jumble up the passwd and userid hardcoded in the swf.

What do you mean HardCoded ("Flash can be decompiled")?

SWF then launches a browser window setting the userid and temppasswd which from then becomes the session passwd.

This is all probably futile anyway, but I am interested how would this type of scenario be hijacked. Could they sniff the session password and unjumble it in time to use it?

Sounds like the session id is in the URL, which makes hi-jacking the session easier. [Examples + Resource]

I am looking for a way to get some computer info so its only good for that computer. I dont know what I should be looking for.

There are a few commonly used identifiers, however these have flaws too. (MAC ADDRESS | HARD DISK S/N | CPU ID | OS ID) Using a combination of these would help, and make it a little more difficult

Off Topic:

Why do I feel like i'm repeating myself

[whiterabbit]

As to how someone can actually hi-jack a session...

Good Article, I will have to read it a few more times to understand it better but it seems that if an attacker can get in to your server then you have lost anyway.

Regardless, of the medium used, never trust the client. Do not cache username/passwords or any private data on the client.

Okay. The idea was to protect against sniffing the password on an inta/internet and from spyware on the client so hard coding the pass was stupid, I know swf's can be decompiled.

Sounds like the session id is in the URL, which makes hi-jacking the session easier

No. The swf is only used for login and the jumbled passwd and id are sent using POST. After that the temp passwd is created and gets passed as a session variable.

There are a few commonly used identifiers, however these have flaws too.

I have to read the article again. It all starts to seem like a lost cause. We don't have that many clients, say 200. Is there another approach say like using a vpn...or ??

We want it convenient for the client to login but we do not need to provide an easy means for registration. In other words we can physically access the clients computer to set something up.

Sorry for the boring repitios subject, next time your in sunny Miami, I will buy you a beer

Cheers

[Andrew-J2000]

Okay. The idea was to protect against sniffing the password on an inta/internet and from spyware on the client so hard coding the pass was stupid, I know swf's can be decompiled.

No. The swf is only used for login and the jumbled passwd and id are sent using POST. After that the temp passwd is created and gets passed as a session variable.

I have to read the article again. It all starts to seem like a lost cause. We don't have that many clients, say 200. Is there another approach say like using a vpn...or ??

We want it convenient for the client to login but we do not need to provide an easy means for registration. In other words we can physically access the clients computer to set something up.

I previously mentioned 'Security is always a compromise between performance.', I must include usability and deployment as other factors.
Theres no problem using SWF for the client to access the server, however I would recommend using SSL to connect to the server; ensure you sign the cookie over SSL as secure and that the server ensures the connection as secure. Using a cookie as a token to authenticate clients, and providing it's clearly thought out, can be secure enough.

Different scenarios offer different solutions, especially when security and interoperability are concerned. So when you refer to clients, are these partners or customers? As you mention you have access to there computers? If these are partners, I would recommend deploying a certificate, which you can use to verify the partner as a user, and ensure that they enter a form of credential to verify the current user.

Off Topic:


I would give you a demonstration of the above, although I cannot find the example. From what I remember it was named something like CIRCB and was published from a university,, if I remember correctly. Hopefully someone can find it again.

Lately, i've found Google pretty useless, taking me time to search for topics of interest, am I the only one being flooded with poor information, when searching for sites or specifics?

[Widow Maker]

...never trust the client. Do not cache username/passwords or any private data on the client.

Doesn't matter what shape or form the data is, never ever trust it

Specially nowadays, security should be the number one concern for the Internet, IMO above anything else.

[whiterabbit]

Yes I agree that security is very important someone with motive might instigate an attack. In such a case the damage would be minimal but the loss of confidence from the client is what we worry about.


The clients (Banks,Hmo's, etc) are not partners but we have to work together so a high level trust and cooperation is needed.

Using a certificate assigned to clients sounds like something I would like to investigate and yes we would log them in using SSL. Maybe that will be enough as you say. If anyone knows more about this approach please comment.

Thanks.

....right on about the google thing.

[josheli]

like everything else on this forum, i think the security paranoia is a little overblown. has anyone here ever suffered from their data being sniffed on the wire and hacked? from their sessions being hijacked? ok, here comes everyone out of the woodwork.... but i'm just trying to get a sense of the problem.

as developers, you probably use ftp alot: clear text. you login to this site and dozens others: clear text. you use basic authentication: little more than clear text. and i bet a lot of people use the same password for multiple sites.

and what are you securing? the majority of the time it's an "article" site or something equally unspectacular.

if you're handling something really sensitive like credit card data, then of course you should be using SSL and either not storing it on your server or encrypting it.

as someone else said, once someone gets access to your server, game over.

btw, of course you can also encrypt the session data. just yesterday i had a case where i needed to store the user/password of a non-sensitive site, without using a database. i think this is secure enough for the task:

//this can be hard coded or come from the client like the 
//javascript rand id that Yahoo uses
$unique = md5('Q42Taw7f0dd4');
session_save_path('/some/dir/not/in/webroot');
session_start();

//these will be the session keys for the crypt key and the string data
$k = md5($unique);
$s = md5($k);

//first access of page from a form
if(isset($_POST['_user']) && isset($_POST['_pass']) && !isset($_SESSION[$k]) && !isset($_SESSION[$s])){
    $u = trim(strip_tags($_POST['_user']));
  $p = trim(strip_tags($_POST['_pass']));
    
  //the data as a string
  $data = "$u~~$p";
    
  //the crypt key, stored in the unique session variable
  $_SESSION[$k] = md5(uniqid(mt_rand(), true));
    
  //encrypt the data
  $_SESSION[$s] = encrypt($data, $_SESSION[$k]);
/*
ends up like this:
187de669c5769b2779de7d38a2573684|s:32:b570689346a15f4a8dbcae4f00c80244;
 f2351ad23be1d12a3f895487381d419b|s:38:ÚÓ¸TYM™€[àsé\©~ëî•ÂÉ3Ïâh5o�ιÿTè
*/
}

//decrypt and retrieve the data
if(isset($_SESSION[$s]) && isset($_SESSION[$k])){
    $data = explode('~~',decrypt($_SESSION[$s], $_SESSION[$k]));
    $user = $data[0];
    $pass = $data[1];
}
else {
    echo 'Could not validate';
    exit;
}

/* From PHP user notes:
robert at peakepro dot com
03-Mar-2004 09:25
*/
function encrypt($string,$key) {
   srand((double) microtime() * 1000000); //for sake of MCRYPT_RAND
  $td = mcrypt_module_open('des', '','cfb', '');
  $key = substr($key, 0, mcrypt_enc_get_key_size($td));
  $iv_size = mcrypt_enc_get_iv_size($td);
  $iv = mcrypt_create_iv($iv_size, MCRYPT_RAND);
  /* Initialize encryption handle */
   if (mcrypt_generic_init($td, $key, $iv) != -1) {

     /* Encrypt data */
     $c_t = mcrypt_generic($td, $string);
     mcrypt_generic_deinit($td);
     mcrypt_module_close($td);
       $c_t = $iv.$c_t;
       return $c_t;
   } //end if
}

function decrypt($string,$key) {
  /* Open module, and create IV */
  $td = mcrypt_module_open('des', '','cfb', '');
  $key = substr($key, 0, mcrypt_enc_get_key_size($td));
  $iv_size = mcrypt_enc_get_iv_size($td);
  $iv = substr($string,0,$iv_size);
  $string = substr($string,$iv_size);
  /* Initialize encryption handle */
   if (mcrypt_generic_init($td, $key, $iv) != -1) {

     /* Encrypt data */
     $c_t = mdecrypt_generic($td, $string);
     mcrypt_generic_deinit($td);
     mcrypt_module_close($td);
       return $c_t;
   } //end if
}

//etc..... 

[Dark Tranquility]

php-sessions are vulnerable to fixation-attacks as outlined in
http://de2.php.net/manual/en/ref.session.php
-> http://www.acros.si/papers/session_fixation.pdf

kai

Quite intersting stuff !! thanks

[depaula]

i am new with php. how can i use finger print scanner with php?
does it work to any fingerprint reader like the one in the ebay.com "Microsoft USB Fingerprint Reader"?

i will gladly apprciate your response...