Proposal for securing PHP sessions
Mar Tin
Dear all:
Until I read the article "PHP Session security"
(http://www.webkreator.com/php/configuration/php-session-security.html)
I haven't noticed how insecure PHP Sessions are.
Basically there're 2 problems:
*) It's possible to hijack a session if you know the
SID (session id)
1) If you're on a shared server (cheap webhosting)
other users can get the SIDs by doing "ls /tmp/sess_*"
(/tmp/ is defined on session.save_path on the config
file, so it may be different).
2) When a user clicks on an external link, the
browser sends the REFERER url and sometimes it
contains the SID (if session.use_trans_sid is enabled)
PHP offers a security measure: with
session.referer_check it will reject SIDs comming from
other referers, but the referer url can be easily
forged.
*) Users can read session data from the session files,
which are owned by the server process (every user
which has an account on the webserver can read server
owned files)
(If you're intrested in the subject I would recommend
to read full the article:
http://www.webkreator.com/php/configuration/php-session-security.html)
I have developed some functions to avoid this
problems. They replace the standard session functions
(using session_set_save_handler), so you only have to
include the file at the beggining of your script and
(afaik) you're safe :)
This is the idea:
Apart from the session cookie, I set another one (with
the same name and the string '_sec' appended). On this
cookie I set a random KEY.
The name of the file which contains the session data
is the md5 hash of the SID and the KEY together. This
turns impossible to guess the session id by looking at
the filenames.
To hide the data inside the file, the serialized
string is crypted using the KEY as password, so nobody
can see the content of your user's sessions.
You can find the code here:
http://www.n3rds.com.ar/files/docs/php_sessions/sess_handler.txt
Im looking for suggestions to make it 100% compatible
with the standard session functions, and I would like
to hear some thougts about the idea
Martin Sarsale
mar...@n3rds.com.ar
__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com
M1tch
I created a nice system, whereby if your IP is changed (or someone is
hacking your session), the session is destroyed, and the user must log in.
Does not add much overhead either.
Also, I built it using database (using my own session functions in
savehandler), that stores the ip as well.
This prevents people snooping.
Still not 100% secure I imagine, but much better.
Andy
"Mar Tin" <runa...@yahoo.com> wrote in message
news:2002090716130...@web14510.mail.yahoo.com...
Dave At Sinewaves.Net
if you do that, as AOL changes a user's IP address about as often as you
read the word "the"...
Dave
Andy
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Philip J. Newman
kill most of New Zealand and Oz
M1tch
that was possible...
I only use sessions to store username/password and other limited variables,
it's only if they log off and back in again that's they have to log out, and
separate cookies automatically handle the login there- so it's pretty
seamless.
Anyone know about server farms? I vaguely remember reading that you should
only use the first three portions of an IP address (e.g. 123.12.123) to be
sufficient for a server farm.
"Dave At Sinewaves.Net" <eigh...@earthlink.net> wrote in message
news:ELENILOLLHIDAONECKO...@earthlink.net...
Justin French
> Why not just use IP?
> I created a nice system, whereby if your IP is changed (or someone is
> hacking your session), the session is destroyed, and the user must log in.
> Does not add much overhead either.
large ISPs like AOL use variable IPs (your IP could change from page to
page)... that's a pretty good reason to start with.
if people get disconnected, they too are likely to have a new IP on most
dial-up ISPs.
Justin
M1tch
"Justin French" <jus...@indent.com.au> wrote in message
news:B9A0FB44.FFD9%jus...@indent.com.au...
M1tch
remains static when AOL changes it? Even if it's only the first part, that's
better than nothing.
I'm having a headache now, because I'm already behind schedule, and this has
just thrown a spanner in the works :( (but still thanks for bringing it up
now, rather than at production time!)
"Justin French" <jus...@indent.com.au> wrote in message
news:B9A0FB44.FFD9%jus...@indent.com.au...
M1tch
yours, but unfortunately the page (well, the entire site), will not load.
It could be a temporary outage with either ISP, but is there anyway you
could post it here? (I perhaps flag it as large?).
On my site, I'm not really bothered about most of the session data being
hijacked, because a user would still not be able to be malicious (any
serious function- like post article/forum message/etc) has a permission
check before it's executed, that verifies the username/password.
Of course, this then becomes a problem if the user has stored the password
in session, as this is the sensitive part.
Why oh why is AOL so terrible. I didn't like them before, but now! Grrrrr
Andy
"Mar Tin" <runa...@yahoo.com> wrote in message
news:2002090716130...@web14510.mail.yahoo.com...
>
M1tch
source you posted. Looking it over!
"M1tch" <m1tc...@hotmail.com> wrote in message
news:200209081035...@pb1.pair.com...
M1tch
Every time a session is opened, the system insists on writing to disk on
every page, whether the session is updated or not.
With a lot of users, this is a bit of a system bog.
So, I hold the contents of a session when 'read', in a global variable.
Then, in the write function, I see if it's changed. If it has, I do the
write. If it hasn't, I simply return from the function.
"Mar Tin" <runa...@yahoo.com> wrote in message
news:2002090716130...@web14510.mail.yahoo.com...
>
Justin French
that you don't trust anything client side, which would include IP address'.
Even if you could get it working for AOL, what about some other ISP located
in Australia, South Africa, or anywhere else on the planet that you've never
heard of?
Don't trust IPs. AOL was just an example.
Justin
Chris Shiflett
unfortunately haven't had time to look at your code (thus, I'm just
going by your description).
Due to frequent vulnerabilities found in Internet Explorer's cookie
handling (versions 4.0 - 6.0 allow anyone to view cookies from any
domain, regardless of the cookie's characteristics), cookies should be
considered public by any system attempting to be secure. Meaning, if
both your key that you describe as well as the session ID are stored in
cookies, a compromise of both these cookies opens you up to a
presentation attack. This does not require the attacker to sniff the
HTTP traffic in any way, so even the use of another security method such
as SSL does not prevent this type of attack.
Instead, you should consider some sort of combination approach, where
you utilize both URL variables and cookies. URL variables are quite
exposed (and can be revealed with the Referer HTTP header), so you want
to make the exposure of this by itself useless to an attacker. At the
same time, you want a cookie compromise to not compromise your entire
mechanism. By requiring both types of attacks, you at least make a
compromise more difficult and therefore slightly strengthen what you've
already got.
Hope that helps. Happy hacking.
Chris