_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_path("/home/mydomain/public_html/lists");
session_name('login_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($_SESSION['superuser']))
return 'superuser';
if (isset($_SESSION['customer']))
return 'customer';
if (isset($_SESSION['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($_SESSION['admin']))
unset($_SESSION['customer']);
if (isset($_SESSION['superuser']))
unset($_SESSION['superuser']);
header("Location: http://www.example.com/userindex.php");
} else header("Location: http://www.example.com/login.php?error=1")
} else header("Location: 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_cookie_params();
$_SESSION = array(); // unset all session values

if ((empty($CookieInfo['domain'])) && (empty($CookieInfo['secure'])))
setcookie(session_name(), '', time()-3600, $CookieInfo['path']);
elseif (empty($CookieInfo['secure']))
setcookie(session_name(), '', time()-3600, $CookieInfo['path'],
$CookieInfo['domain']);
else
setcookie(session_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

[Rik]

axlq wrote:

So here's my logout.php script for all
user types. It does seem to work correclty:

I'm missing session_start() here.....

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

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

What if you just:

session_save_path('/home/mydomain/public_html/lists');
session_name('login_settings');
session_start();
set_cookie(session_name(),'',time()-3600,'/');//or your snippet offcourse
$_SESSION = array();
session_destroy();

Else, I'm very curious wether you cookies are actually deleted or not, and
if not, what they hold.

Grtz,
--
Rik Wasmus

[axlq]

In article <48***************************@news2.tudelft.nl> ,
Rik <lu************@hotmail.comwrote:

>axlq wrote:

> So here's my logout.php script for all
user types. It does seem to work correclty:

I'm missing session_start() here.....

Not really... as I said at the beginning of my original post,
*all* scripts - without exception - include a file that calls
session_start() right at the beginning. I neglected to say that
what I posted for logout.php was an excerpt, not the whole script.

>What if you just:

session_save_path('/home/mydomain/public_html/lists');
session_name('login_settings');
session_start();
set_cookie(session_name(),'',time()-3600,'/');//or your snippet offcourse
$_SESSION = array();
session_destroy();

That's what it does already.

>Else, I'm very curious wether you cookies are actually deleted or
not, and if not, what they hold.

The cookie gets deleted. When I examine the cookie after logging
off in Opera, it says "login_settings: deleted."

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.

-A

[Rik]

axlq wrote:

In article <48***************************@news2.tudelft.nl> ,
Rik <lu************@hotmail.comwrote:

>axlq wrote:

>> So here's my logout.php script for all
user types. It does seem to work correclty:

I'm missing session_start() here.....

Not really... as I said at the beginning of my original post,
*all* scripts - without exception - include a file that calls
session_start() right at the beginning. I neglected to say that
what I posted for logout.php was an excerpt, not the whole script.

Sorry, missed that. As it is an excerpt, are you sure everything get's
executed correctly? No notices when error_reporting(E_ALL)?

>Else, I'm very curious wether you cookies are actually deleted or
not, and if not, what they hold.

The cookie gets deleted. When I examine the cookie after logging
off in Opera, it says "login_settings: deleted."

Hmmz, then I don't think the problem is there. What's the actual content of
/home/mydomain/public_html/lists")? Are the sessions cleaned up?

It could also have something to do with the actual logging in/checking,
maybe post a portion of that code.

Grtz,
--
Rik Wasmus

[Jerry Stuckle]

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.

-A

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.

However, that also depends on your PHP.INI file. You should have

session.use_cookies = 1

in your php.ini file.

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.

I'm also not sure why you're using set_cookie on the session name.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================

[axlq]

In article <8o******************************@comcast.com>,
Jerry Stuckle <js*******@attglobal.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.

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

It's set that way already.

>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_path 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.

>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

[Miguel Cruz]

ax**@spamcop.net (axlq) wrote:

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.

Have you tested this in other NAT environments? The behavior you
describe is not how PHP normally works. I wonder if you are, perhaps
unbeknownst to you, sitting behind a faulty http proxy.

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

[axlq]

In article <98*************************@news2.tudelft.nl>,
Rik <lu************@hotmail.comwrote:

>are you sure everything get's executed correctly? No notices when
error_reporting(E_ALL)?

Good idea. No unusual notices came from error_reporting(E_ALL)
- just some instances of testing values of nonexistent variables
instead of using isset(), which doesn't affect the logical execution
of the code and isn't related to the problem at hand.

However, my testing to see if the error reporting gave any surprises
*did* clarify that the problem arises from the 'sess_deleted' files
that are left behind in my session path when logging off. It seems
that the 'sess_deleted' file is actually being used as a session ID.

Here is what seems to be wrong:

A. After logging off, re-logging in doesn't re-set the session
cookie. It persists as having the value 'deleted', which is how it
gets set after using set_cookie() with a timestamp of time()-3600 to
force the cookie to expire.

B. The session file 'sess_deleted' - which appears from
session_destroy() in the logoff script - is used as an actual
session by browsers with a 'login_settings' cookie set to 'deleted'.
Any $_SESSION values introduced by one browser become part of the
$_SESSION in all browsers.

==========

Here's what I did. The first 5 steps are set-up steps.

1. Choose two computers on my end, delete the cookies and clear the
browser cache to start fresh. I also delete any session files in my
session_path on the server, just to make sure it's fresh on that end.

2. Computer A: I open up the Opera browser log in as a normal user.
A session cookie appears in the cookie list, and a file called
sess_99eae3b908fa57142f08f31a7eafc6c2 appeared in my session_path
when the browser first accessed the site.

3. Computer A (again): I open up the Firefox browser and log in
as a customer. A session cookie is set properly in the browser,
and a new file sess_4dd766f5f0bb86404b1e6d872e59035e appears in my
session_path.

4. Computer B: Open up the IE browser and log in as superuser.
A new file sess_92d1cd69bb176cb4167c08220af30be7 appears.
Everything fine so far. So far all three computers are working fine
independently. No surprises from E_ALL error reporting.

5. I log off computer B. The session file disappears and becomes
'sess_deleted' instead. The two browsers on computer A still behave
properly.

OK. HERE'S WERE IT GETS WEIRD.

6. I log off the Opera browser in computer A. The session file
disappears. The browser displays the non-logged-in index page,as it
should. However... there is still ONE 'sess_deleted' file, but with
a new timestamp.

7. I re-log in computer B as superuser. The superuser index page
appears, but no new session file is created! Nothing strange
appears in the E_ALL errors.

8. From computer A, I re-load the non-logged-in index page in Opera.
It loads up the superuser index page that B is seeing! Opera's
cookie manager says of the session cookie, "login_settings: deleted"

9. All this time, the Firefox browser on computer A has
been operating normally in its own session. There has been
no interference so far. Now I log off. The session file
disappears. The browser loads the superuser index page instead of
the non-logged-in index page! Firefox says of the session cookie:
Name: login_settings
Content: deleted

10. Logging off from 'superuser' from any computer logs off all
browsers. There is still one 'sess_deleted' file in my session_path
with a timestamp updated to the logoff time.

>It could also have something to do with the actual logging in/checking,
maybe post a portion of that code.

It now seems to have everything to do with sess_deleted and session
cookies set to 'deleted'. My logoff script follows the example shown
in http://us2.php.net/manual/en/functio...on-destroy.php

-A

[axlq]

In article <spam-A7BC28.00113331072006@localhost>,
Miguel Cruz <sp**@admin.u.nuwrote:

>ax**@spamcop.net (axlq) wrote:

>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.

Have you tested this in other NAT environments? The behavior you
describe is not how PHP normally works. I wonder if you are, perhaps
unbeknownst to you, sitting behind a faulty http proxy.

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.

-Alex

[axlq]

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_regenerate_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.

-Alex

[Jerry Stuckle]

axlq wrote:

In article <8o******************************@comcast.com>,
Jerry Stuckle <js*******@attglobal.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_cookies = 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_path 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*******@attglobal.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_regenerate_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('check_name');
session_start();
$_SESSION['var1'] = 'something';
?>

file2.php

<?php
session_name('check_name');
session_start();
$_SESSION = array();
setcookie(session_name(),'',time()-3600,'/');
session_destroy();
?>

There doesn't appear a 'sess_deleted' file. the sess_{random_string} 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.comwrote:

>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(session_name(),'',time()-3600,'/');
session_destroy();
?>

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('class_lib/class.setup.php');

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

if ((empty($CookieInfo['domain'])) && (empty($CookieInfo['secure'])))
setcookie(session_name(), '', time()-3600, $CookieInfo['path']);
elseif (empty($CookieInfo['secure']))
setcookie(session_name(), '', time()-3600, $CookieInfo['path'],
$CookieInfo['domain']);
else
setcookie(session_name(), '', time()-3600, $CookieInfo['path'],
$CookieInfo['domain'], $CookieInfo['secure']);
unset($_COOKIE[session_name()]);
session_destroy();
header("Location: ".WWW_PATH."index.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_path(PROG_PATH."/lists");
session_name('login_settings');
session_start();
if (session_id() == 'deleted') session_regenerate_id(true);

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

-Alex

[axlq]

In article <_-******************************@comcast.com>,
Jerry Stuckle <js*******@attglobal.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_path 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_destroy(). 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**********@blue.rahul.net>, axlq <ax**@spamcop.netwrote:

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

I forgot to mention that using session_save_path() 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_path().

-Alex

[Jerry Stuckle]

axlq wrote:

In article <_-******************************@comcast.com>,
Jerry Stuckle <js*******@attglobal.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_globals 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_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_path 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
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_destroy(). 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*******@attglobal.net
==================

[Jerry Stuckle]

axlq wrote:

In article <ea**********@blue.rahul.net>, axlq <ax**@spamcop.netwrote:

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

I forgot to mention that using session_save_path() 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_path().

-Alex

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

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.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*******@attglobal.net
==================

[Miguel Cruz]

ax**@spamcop.net (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

[axlq]

In article <spam-0445EE.04274801082006@localhost>,
Miguel Cruz <sp**@admin.u.nuwrote:

>ax**@spamcop.net (axlq) wrote:
Why don't you log people out by just erasing everything in their session
with session_destroy()?

I do. See the rest of this thread.

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

It probably shouldn't -- I was just going by the documentation for
session_destroy() on php.net, which shows the session cookie being
deleted in its primary example.

-A

[axlq]

In article <FI******************************@comcast.com>,
Jerry Stuckle <js*******@attglobal.netwrote:

>Hmmm, is register_globals 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.

Whether you know it or not, you're using session cookies if you're
not passing the session ID through URLs.

The problem arises, I guess, because I'm deleting the session cookie
before calling session_destroy() -- because the php documentation said
to do that. I guess I don't really need to delete it.

Deleting the cookie gives it the value 'deleted' until the browser
is closed, which matches the sess_deleted file created when
session_destroy() is called. THAT was the whole problem.

-Alex