_SESSION weirdness behind a NAT firewall/router: bug?

[axlq]

Someone please tell me if I've discovered a PHP bug.

I'm sitting in front of several computers on my home network, behind
a NAT firewall/router. I am testing my web site on these different
computers (running different browsers, logged in as different users,
etc.). My web site keeps track of users logged in through the use
of $_SESSION.

Here's the bizarre thing: All computers are logged off, then I log
into my web site with one computer -- and when I browse my site from
another computer it behaves as if logged in! And if I log off with
one computer, all other computers subsequently behave as if logged
off! This happens also with different browsers (say IE and Opera)
running on the same machine.

This is especially serious because I have four classes of users:
non-logged-in visitor, logged-in user, paying customer, and
superuser. Logging in as superuser, for example, gives superuser
privileges to ALL computers on my home network!

AAAARRRGH!! I can't figure this out. It seems that $_SESSION is
using *only* my IP address and no unique identifying information
from the browsers on my network. Is this a php bug?

Background:

Here is basically what I'm doing. All scripts first contain a
require_once() directive that includes a file which executes the
following statements right up front:

session_save_pa th("/home/mydomain/public_html/lists");
session_name('l ogin_settings') ;
session_start() ;

(Naturally, the save path exists, and it contains session data
files.) Then, each script calls a function isLoggedOn() to
determine the type of user logged in, if any:

function isLoggedOn()
{
if (isset($_SESSIO N['superuser']))
return 'superuser';
if (isset($_SESSIO N['customer']))
return 'customer';
if (isset($_SESSIO N['user']))
return 'user';
return NULL; // unregistered or not logged in
}

Upon receiving the return value from isLoggedOn(), the script
behaves exactly the way it should depending on what type of user is
logged in. The value of $_SESSION['user'], $_SESSION['customer'],
and $_SESSION['superuser'] is the user's ID in the MySQL table for
that user type; the value is set by a login.php script.

I have three login.php scripts: for normal users, customers, and
superuser. Each login.php script queries the appropriate database
for user ID and password, and then sets some $_SESSION values.
Here, for example, is what happens with $_SESSION when a normal user
logs in. Note that it ensures that the customer and superuser types
are unset upon this login:

if ($sql->rows) {
$userid = $sql->GetValue('id') ;
if ($userid) {
$_SESSION['user'] = $userid;
if (isset($_SESSIO N['admin']))
unset($_SESSION['customer']);
if (isset($_SESSIO N['superuser']))
unset($_SESSION['superuser']);
header("Locatio n: http://www.example.com/userindex.php") ;
} else header("Locatio n: http://www.example.com/login.php?error =1")
} else header("Locatio n: http://www.example.com/login.php?error =1")

Logging off shouldn't leave anything behind from prior users,
deleting all $_SESSION data, killing the session cookie, and finally
calling session_destroy (). So here's my logout.php script for all
user types. It does seem to work correclty:

$CookieInfo = session_get_coo kie_params();
$_SESSION = array(); // unset all session values

if ((empty($Cookie Info['domain'])) && (empty($CookieI nfo['secure'])))
setcookie(sessi on_name(), '', time()-3600, $CookieInfo['path']);
elseif (empty($CookieI nfo['secure']))
setcookie(sessi on_name(), '', time()-3600, $CookieInfo['path'],
$CookieInfo['domain']);
else
setcookie(sessi on_name(), '', time()-3600, $CookieInfo['path'],
$CookieInfo['domain'], $CookieInfo['secure']);
unset($_COOKIE[session_name()]);
session_destroy ();

I'm at my wit's end, almost ready to manage my own cookies and dump
this PHP session handling stuff. I'd rather not though; I like
having the one session cookie with sensitive data stored on the
server. *Other* sites don't behave this way if I log into them
simultaneously from different computers on my home network. What's
wrong with MY site??

-Alex

[Jerry Stuckle]

axlq wrote:

In article <8o************ *************** ***@comcast.com >,
Jerry Stuckle <js*******@attg lobal.netwrote:

>>axlq wrote:

>>>The real problem is that the web hosting server seems to think that
every computer on my home network shares the same session ID, and I
don't know what to do about it. I haven't made the web site public
yet. I certainly can't do so as long as $_SESSION poses such a huge
security risk. There are much more than just home networks behind
NAT firewall/routers. If multiple people in a large organization
try to access my site, all kinds of conflicts will occur.

The web server doesn't keep track of the session like that. It sends a
cookie to the browser with the session id, and the browser keeps track
of the id.

It sends a cookie to ONE browser. Once this cookie is set and the
session established on the server, the cookie doesn't seem to get
used any more.

It does on my systems. But all I uses is session_start() - not all the
rest of the stuff you use.

>

>>However, that also depends on your PHP.INI file. You should have
session.use_c ookies = 1
in your php.ini file.

It's set that way already.

Then it should use cookies automatically, You shouldn't need the rest
of it that stuff.

>

>>But I'm also not sure why you're using those other calls - such as
session_save_ path and session_name(). These should be set up in your
php.ini file and you shouldn't need to override them.

Two reasons:

1. This is a shared server, I don't own php.ini, I didn't want to
use the /tmp path already set in it, and I didn't like the default
session name set in it.

2. I can set my own php.ini, but I may have multiple web sites under
the same account, so I preferred having each site's sessions have
their own path -- therefore I set session_save_pa th and session_name
in the script. It shouldn't make any difference as long as these
settings are consistent in every invocation of my scripts.

So? It's a shared server. Sure, someone can access your session info
in /tmp - but only if they know the session id, which is VERY hard to
guess. And BTW - the could access the information in your own
directory, also. This is worse than no security - it is false security;
making you think your data is safe when you've actually gained nothing.

Just don't keep sensitive information like passwords in the session.
Or, if you must, encrypt it.

>

>>I'm also not sure why you're using set_cookie on the session name.

That's only to delete the session cookie when logging off. This was
recommended in a php documentation page somewhere, so I pretty much
just lifted the code from there. set_cookie isn't used anywhere else
on my site except for the one logoff script.

-A

Whatever. Works fine for me without it just by calling
session_destroy (). Then the cookie would have an invalid session ID,
which is just fine, also.

I don't think this is a PHP problem - it's in something you're doing.
Check phpinfo() to ensure your settings are as you expect and you're
using the php.ini you think you're using.

As for other browsers getting the session information - the only way
they would get this is if the server were sending the same information
and/or the pages are cached somewhere between the server and your
internal network.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Rik]

axlq wrote:

Followup to my own post. I think I have solved the problem by
forcing regeneration of the session ID if the session ID has the
value 'deleted' -- like this:

session_start() ;
if (session_id() == 'deleted')
session_regener ate_id(true);

As far as my tests have shown, this prevents multiple browsers
from sharing the 'sess_deleted' session file on the server, if
those browsers have a deleted session cookie and are attempting to
re-log-in to my site.

This has nothing to do with being behind a NAT.

Hmmm, when I

file1.php
<?
session_name('c heck_name');
session_start() ;
$_SESSION['var1'] = 'something';
?>

file2.php

<?php
session_name('c heck_name');
session_start() ;
$_SESSION = array();
setcookie(sessi on_name(),'',ti me()-3600,'/');
session_destroy ();
?>

There doesn't appear a 'sess_deleted' file. the sess_{random_st ring} file
just disappears. This is also true with a custom save path. Even adding a
session_start() directly after it, or on a redirect, will create a totally
new unique sess_file.

Allthough you have a workaround now, could you maybe post you total logout
script (for I still think there's the error) and not just the excerpt?
Otherwise, it will haunt me for days :-)

Grtz,
--
Rik Wasmus

[axlq]

In article <53************ *************** @news2.tudelft. nl>,
Rik <lu************ @hotmail.comwro te:

>Hmmm, when I

file1.php
<?
session_name(' check_name');
session_start( );
$_SESSION['var1'] = 'something';
?>

file2.php

<?php
session_name(' check_name');
session_start( );
$_SESSION = array();
setcookie(sess ion_name(),'',t ime()-3600,'/');
session_destro y();
?>

There doesn't appear a 'sess_deleted' file.

Do you access file1.php and file2.php from your browser, and keep your
browser open? Does your session cookie have the value 'deleted'?

According to the documentation at
http://www.php.net/manual/en/ref.session.php I'm not the only one
who sees a sess_deleted file when terminating a session. Maybe it's
an Apache thing for my ISP's particular configuration of the server.

>Allthough you have a workaround now, could you maybe post you total
logout script (for I still think there's the error) and not just
the excerpt? Otherwise, it will haunt me for days :-)

No problem, but it's several files. I think you might have a server
configuration that simply won't create a sess_deleted file.

logout.php:
=============== =============== =============== =============== ========
<?php
require_once('c lass_lib/class.setup.php ');

$CookieInfo = session_get_coo kie_params();
$_SESSION = array(); // unset all session values

if ((empty($Cookie Info['domain'])) && (empty($CookieI nfo['secure'])))
setcookie(sessi on_name(), '', time()-3600, $CookieInfo['path']);
elseif (empty($CookieI nfo['secure']))
setcookie(sessi on_name(), '', time()-3600, $CookieInfo['path'],
$CookieInfo['domain']);
else
setcookie(sessi on_name(), '', time()-3600, $CookieInfo['path'],
$CookieInfo['domain'], $CookieInfo['secure']);
unset($_COOKIE[session_name()]);
session_destroy ();
header("Locatio n: ".WWW_PATH."ind ex.php");
?>
=============== =============== =============== =============== ========

That big 'if' statement above to delete the session cookie is
lifted directly from the example at the bottom of this page:
http://us3.php.net/manual/en/functio...on-destroy.php

class_lib/class.setup.php contains the following at the beginning; the
rest is smarty template manager setup needed by all scripts except
logout.php, so that stuff isn't relevant.

class_lib/class.setup.php :
=============== =============== =============== =============== ========
<?php
// configs.php defines PROG_PATH, WWW_PATH, and a bunch of other stuff
require_once('/home/mydomain/public_html/configs.php');

session_save_pa th(PROG_PATH."/lists");
session_name('l ogin_settings') ;
session_start() ;
if (session_id() == 'deleted') session_regener ate_id(true);

/* smarty setup class and isLoggedOn() function goes here... */
?>
=============== =============== =============== =============== ========

-Alex

[axlq]

In article <_-*************** *************** @comcast.com>,
Jerry Stuckle <js*******@attg lobal.netwrote:

>It sends a cookie to ONE browser. Once this cookie is set and the
session established on the server, the cookie doesn't seem to get
used any more.

It does on my systems. But all I uses is session_start() - not all the
rest of the stuff you use.

Sorry for my sloppiness - the cookie gets READ, but only WRITTEN
once upon the first access to the site, and then again when it's
deleted. If the value of the cookie matches the file name of a
session, it seems to be considered a valid session cookie. So if
the cookie has the value 'deleted' (which session cookies do until
you close the browser), and it matches the ID for sess_deleted on
the server, then sess_deleted gets used for the session, causing
user account collisions.

>>>But I'm also not sure why you're using those other calls - such as
session_save _path and session_name(). These should be set up in your
php.ini file and you shouldn't need to override them.

Two reasons:

1. This is a shared server, I don't own php.ini, I didn't want to
use the /tmp path already set in it, and I didn't like the default
session name set in it.

2. I can set my own php.ini, but I may have multiple web sites under
the same account, so I preferred having each site's sessions have
their own path -- therefore I set session_save_pa th and session_name
in the script. It shouldn't make any difference as long as these
settings are consistent in every invocation of my scripts.

So? It's a shared server. Sure, someone can access your session info
in /tmp - but only if they know the session id, which is VERY hard to
guess. And BTW - the could access the information in your own
directory, also.

No, they can't. How? An .htaccess file prevents any kind of access
through the web server, and the session files have permissions only
for apache.

>Just don't keep sensitive information like passwords in the session.

I don't. Submitting a correct password during login is what
establishes the session data, which consists of just basic
information like the user ID and last page accessed.

>>>I'm also not sure why you're using set_cookie on the session name.

That's only to delete the session cookie when logging off. This was
recommended in a php documentation page somewhere, so I pretty much
just lifted the code from there. set_cookie isn't used anywhere else
on my site except for the one logoff script.

Whatever. Works fine for me without it just by calling
session_destro y(). Then the cookie would have an invalid session ID,
which is just fine, also.

I'm going by the php documentation at
http://www.php.net/manual/en/functio...on-destroy.php which
states: "In order to kill the session altogether, like to log the
user out, the session id must also be unset. If a cookie is used to
propagate the session id (default behavior), then THE SESSION COOKIE
MUST BE DELETED" (emphasis mine). The example that follows this
sentence shows how to kill the cookie. I use the expanded example
given at the very bottom of that page.

>I don't think this is a PHP problem - it's in something you're doing.

It's neither a problem or something I'm doing; it's a feature :)

>Check phpinfo() to ensure your settings are as you expect and you're
using the php.ini you think you're using.

They are and I am.

>As for other browsers getting the session information - the only
way they would get this is if the server were sending the same
information and/or the pages are cached somewhere between the
server and your internal network.

Well, one way the problem could happen is if two or more browsers
have the same session ID set in their cookie. And that's exactly
what happened here: other browsers have identical cookies, with
the value 'deleted' for the session ID, which corresponds to the
sess_deleted file on the server.

I believe this should even work for valid session IDs if you knew
a valid id and spoofed it from another browser. Log in with one
browser to get a session id, then manually edit the cookie in
another browser to be identical to that in the first browser. Now
both browsers will act as if they're logged into the same user
account.

-Alex

[axlq]

In article <ea**********@b lue.rahul.net>, axlq <ax**@spamcop.n etwrote:

>>>>But I'm also not sure why you're using those other calls - such as
session_sav e_path and session_name().

I forgot to mention that using session_save_pa th() set to your own
directory is one way to avoid an early 20-minute session expiration
that one gets on some servers if using the default path. I was
experiencing that. So I went on a search for the reason, during
which I found the trick with session_save_pa th().

-Alex

[Jerry Stuckle]

axlq wrote:

In article <_-*************** *************** @comcast.com>,
Jerry Stuckle <js*******@attg lobal.netwrote:

>>>It sends a cookie to ONE browser. Once this cookie is set and the
session established on the server, the cookie doesn't seem to get
used any more.

It does on my systems. But all I uses is session_start() - not all the
rest of the stuff you use.

Sorry for my sloppiness - the cookie gets READ, but only WRITTEN
once upon the first access to the site, and then again when it's
deleted. If the value of the cookie matches the file name of a
session, it seems to be considered a valid session cookie. So if
the cookie has the value 'deleted' (which session cookies do until
you close the browser), and it matches the ID for sess_deleted on
the server, then sess_deleted gets used for the session, causing
user account collisions.

Hmmm, is register_global s on in your system? That could be part of what
you're seeing. But again - I don't use cookies to keep track of
sessions. I let the session take care of itself and just destroy it at
the end.

>

>>>>But I'm also not sure why you're using those other calls - such as
session_sav e_path and session_name(). These should be set up in your
php.ini file and you shouldn't need to override them.

Two reasons:

1. This is a shared server, I don't own php.ini, I didn't want to
use the /tmp path already set in it, and I didn't like the default
session name set in it.

2. I can set my own php.ini, but I may have multiple web sites under
the same account, so I preferred having each site's sessions have
their own path -- therefore I set session_save_pa th and session_name
in the script. It shouldn't make any difference as long as these
settings are consistent in every invocation of my scripts.

So? It's a shared server. Sure, someone can access your session info
in /tmp - but only if they know the session id, which is VERY hard to
guess. And BTW - the could access the information in your own
directory, also.

No, they can't. How? An .htaccess file prevents any kind of access
through the web server, and the session files have permissions only
for apache.

Very simple. Everyone on the server is using the same Apache - and
therefore the same Apache user. They can easily write a PHP, PERL or
whatever program to access files from their server to your site through
fopen(), etc. Such access also bypasses .htaccess.

>

>>Just don't keep sensitive information like passwords in the session.

I don't. Submitting a correct password during login is what
establishes the session data, which consists of just basic
information like the user ID and last page accessed.

>>>>I'm also not sure why you're using set_cookie on the session name.

That's only to delete the session cookie when logging off. This was
recommende d in a php documentation page somewhere, so I pretty much
just lifted the code from there. set_cookie isn't used anywhere else
on my site except for the one logoff script.

Whatever. Works fine for me without it just by calling
session_destr oy(). Then the cookie would have an invalid session ID,
which is just fine, also.

I'm going by the php documentation at
http://www.php.net/manual/en/functio...on-destroy.php which
states: "In order to kill the session altogether, like to log the
user out, the session id must also be unset. If a cookie is used to
propagate the session id (default behavior), then THE SESSION COOKIE
MUST BE DELETED" (emphasis mine). The example that follows this
sentence shows how to kill the cookie. I use the expanded example
given at the very bottom of that page.

Yes, the session id itself should be unset. However, since there is no
data associated with the session (at least after the end of this
script), there should be no problem.

The problem here is where someone uses the presence of the session to
determine whether the user is logged in or not. I use parameters within
the session. And if you call session_destroy () this information is gone
once the current script finishes.

>

>>I don't think this is a PHP problem - it's in something you're doing.

It's neither a problem or something I'm doing; it's a feature :)

>>Check phpinfo() to ensure your settings are as you expect and you're
using the php.ini you think you're using.

They are and I am.

>>As for other browsers getting the session information - the only
way they would get this is if the server were sending the same
information and/or the pages are cached somewhere between the
server and your internal network.

Well, one way the problem could happen is if two or more browsers
have the same session ID set in their cookie. And that's exactly
what happened here: other browsers have identical cookies, with
the value 'deleted' for the session ID, which corresponds to the
sess_deleted file on the server.

I believe this should even work for valid session IDs if you knew
a valid id and spoofed it from another browser. Log in with one
browser to get a session id, then manually edit the cookie in
another browser to be identical to that in the first browser. Now
both browsers will act as if they're logged into the same user
account.

-Alex

Of course, if you go and manually edit the session id you're going to
get an identical session. What else do you expect?

But under normal conditions two browsers should not be getting the same
session id. It's a long (32 char, IIFC) hex value which shouldn't be
duplicated - and shouldn't be guessable by chance.
--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Jerry Stuckle]

axlq wrote:

In article <ea**********@b lue.rahul.net>, axlq <ax**@spamcop.n etwrote:

>>>>>But I'm also not sure why you're using those other calls - such as
>session_sa ve_path and session_name().

I forgot to mention that using session_save_pa th() set to your own
directory is one way to avoid an early 20-minute session expiration
that one gets on some servers if using the default path. I was
experiencing that. So I went on a search for the reason, during
which I found the trick with session_save_pa th().

-Alex

You can also do it by resetting the lifetime with
session_set_coo kie_parms();

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Richard Levasseur]

Jerry Stuckle wrote:

>
Of course, if you go and manually edit the session id you're going to
get an identical session. What else do you expect?

But under normal conditions two browsers should not be getting the same
session id. It's a long (32 char, IIFC) hex value which shouldn't be
duplicated - and shouldn't be guessable by chance.

This also illustrates the use of having a good session_id generator.
Its not impossible to guess a session id using brute force and
statistics. Of course, the attacker needs to generate a large number
of session ids to figure out what ones are possibly active, then figure
out which of those have information he wants. The chances of that are
relatively remote, but not out of the realm of possibility. If you're
really worried about security that much, then its something to keep in
mind.

[Jerry Stuckle]

Richard Levasseur wrote:

Jerry Stuckle wrote:

>>Of course, if you go and manually edit the session id you're going to
get an identical session. What else do you expect?

But under normal conditions two browsers should not be getting the same
session id. It's a long (32 char, IIFC) hex value which shouldn't be
duplicated - and shouldn't be guessable by chance.

This also illustrates the use of having a good session_id generator.
Its not impossible to guess a session id using brute force and
statistics. Of course, the attacker needs to generate a large number
of session ids to figure out what ones are possibly active, then figure
out which of those have information he wants. The chances of that are
relatively remote, but not out of the realm of possibility. If you're
really worried about security that much, then its something to keep in
mind.

Yes, but if you're that worried about security you should have a
dedicated server and perform your own session handling and not leave it
to PHP's default handling.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attgl obal.net
=============== ===

[Miguel Cruz]

ax**@spamcop.ne t (axlq) wrote:

No, as I posted elsewhere in this thread, I've identified the
problem as arising from multiple users sharing the same sess_deleted
session file after logging off and then re-logging in. I think now
it's unlikely to have anything to do with a NAT or http proxy.

I'm not sure what to do about this yet.

Why don't you log people out by just erasing everything in their session
with session_destroy ()?

Does it matter to you whether the session cookie itself is gone?

miguel
--
Photos from 40 countries on 5 continents: http://travel.u.nu
Latest photos: Malaysia; Thailand; Singapore; Spain; Morocco
Airports of the world: http://airport.u.nu