SitePoint Sponsor |
|
User Tag List
Results 1 to 25 of 26
Thread: How secure are sessions in php ?
-
Mar 2, 2004, 09:01 #1
- Join Date
- Dec 2003
- Location
- oz
- Posts
- 819
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
How secure are sessions in php ?
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
-
Mar 2, 2004, 09:10 #2
- Join Date
- Oct 2003
- Location
- €uroLand
- Posts
- 1,340
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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,....).
-
Mar 2, 2004, 09:16 #3
- Join Date
- Jan 2004
- Location
- Planet Earth
- Posts
- 1,764
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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:archTried to upload the PDF, but it was way too big.
-
Mar 2, 2004, 09:19 #4
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.
-
Mar 2, 2004, 11:26 #5
- Join Date
- Jun 2003
- Location
- hamburg, germany
- Posts
- 103
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
-
Mar 2, 2004, 12:18 #6
- Join Date
- Jan 2004
- Location
- Planet Earth
- Posts
- 1,764
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Looking breifly through the PDF, very interesting
Learn something new everyday, need to read some more later but.
-
Mar 3, 2004, 04:10 #7
- Join Date
- Nov 2000
- Location
- Switzerland
- Posts
- 2,479
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Mar 5, 2004, 18:16 #8
- Join Date
- Jan 2004
- Location
- Planet Earth
- Posts
- 1,764
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Mar 16, 2004, 01:37 #9
- Join Date
- Mar 2004
- Location
- Bulgaria
- Posts
- 1
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Mar 16, 2004, 03:33 #10
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by naskovoto
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.Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Mar 16, 2004, 05:22 #11
- Join Date
- Apr 2003
- Location
- Croatia
- Posts
- 14
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
-
Mar 16, 2004, 06:55 #12
- Join Date
- Oct 2003
- Location
- €uroLand
- Posts
- 1,340
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by el8
-
Mar 16, 2004, 07:11 #13
- Join Date
- Apr 2003
- Location
- Croatia
- Posts
- 14
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Mar 16, 2004, 07:55 #14
- Join Date
- Sep 2003
- Location
- Colombia
- Posts
- 21
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
To secure a session look at the configuration file (or .htaccess)
Originally Posted by manual
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS$ d- s+:+ a-- C++> ULS++ P++ L+> !E W+++ N+ o? K? w++>
O---@ M V? PS+ PE Y+ PGP t+ 5- X+++@ R- tv+(++) b++> DI!
D++> G e+> h-- r- y+
------END GEEK CODE BLOCK------
-
Mar 16, 2004, 08:26 #15
- Join Date
- Aug 2001
- Location
- London
- Posts
- 2,475
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by HarryF
- 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.
-
Mar 24, 2004, 12:42 #16
- Join Date
- Apr 2002
- Location
- Miami
- Posts
- 214
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Mar 24, 2004, 13:41 #17
- Join Date
- Jan 2004
- Location
- Planet Earth
- Posts
- 1,764
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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
-
Mar 24, 2004, 15:42 #18
- Join Date
- Aug 2001
- Location
- London
- Posts
- 2,475
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Widow Maker
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.
Originally Posted by whiterabbit
Originally Posted by whiterabbit
Originally Posted by whiterabbit
Originally Posted by whiterabbit
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
-
Mar 25, 2004, 10:00 #19
- Join Date
- Apr 2002
- Location
- Miami
- Posts
- 214
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
As to how someone can actually hi-jack a session...
Regardless, of the medium used, never trust the client. Do not cache username/passwords or any private data on the client.
Sounds like the session id is in the URL, which makes hi-jacking the session easier
There are a few commonly used identifiers, however these have flaws too.
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
-
Mar 25, 2004, 19:38 #20
- Join Date
- Aug 2001
- Location
- London
- Posts
- 2,475
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by whiterabbit
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?
-
Mar 26, 2004, 07:04 #21
- Join Date
- Jan 2004
- Location
- Planet Earth
- Posts
- 1,764
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
...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.
-
Mar 26, 2004, 09:56 #22
- Join Date
- Apr 2002
- Location
- Miami
- Posts
- 214
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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.
-
Mar 26, 2004, 11:01 #23
- Join Date
- Dec 2003
- Location
- with my kids
- Posts
- 116
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
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:
PHP Code://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.....
-
Mar 27, 2004, 02:44 #24
- Join Date
- Sep 2003
- Location
- KSA - UAE
- Posts
- 9,457
- Mentioned
- 8 Post(s)
- Tagged
- 1 Thread(s)
Originally Posted by kaimeder
-
May 16, 2005, 20:59 #25
- Join Date
- May 2005
- Posts
- 1
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
fingerprint scanner w/ php?
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...
Bookmarks