How to check if the session is really destroyed

[yesmaster]

My server is running PHP 4.4.4
I changed the configuration to put the session files in a directory. In my script, I called session_destroy(). I'd expect it to do 2 things:

1. Clear out the $_COOKIE[session_name()] variable
2. Delete the session file sess_#*$!#*$! that corresponds to the session id in the directory.

But none of these happened. Is session_destroy sufficient for destroying the session in this version? And how do you check to see if it is destroyed?
Thanks.

[jatar_k]

to check to see if it is destroyed do this

echo '<pre>before: ';
print_r($_SESSION);
echo '</pre>';

session_destroy();

echo '<p><pre>after: ';
print_r($_SESSION);
echo '</pre>';

[yesmaster]

Thanks, but do you think it should also clear out the cookie value for the session id and delete the session file?

[jatar_k]

if the session is empty then I don't see how it matters

are you just trying to stop session hijacking?

[yesmaster]

Yes.

[coopster]

Did you go to the manual page yet? All you are asking is laid out there ...
session_destroy() [php.net]

[yesmaster]

you mean the FAQ section of this site? or the 'Manual on how to use PHP' in general? If I found it there I wouldn't have posted the question. Or may be you can show me the link..

[yesmaster]

Oops, got the link. Yes, had been there but it doesn't tell you whether the file sess_#*$!#*$!x is deleted or not.

[coopster]

It says "Destroys all data registered to a session" which means the filesystem file you are referring to in a default session setup (sess_blahblahblah). If you were running a custom session_handler then you would rub out the session data yourself.

[yesmaster]

Yes, I know what it said, but the file sess_#*$!#*$! was not destroyed, I tested this serveral times. that was why I posted the question.

[coopster]

Well, the COOKIE won't be removed automatically, you have to use setcookie() to do that as the manual link above demonstrates. However, the session data should indeed be destroyed. It won't get rid of the file itself, just the data within the file (it will have zero bytes but the file will indeed still exist). The garbage collection routines will remove the empty file when it runs.

[jatar_k]

the file isn't destroyed as far as I know but it is empty

so if you are validating your session then it won't validate because there is no data in there

hijacking is multi tiered

good destruction
strict time limits
as much user identification as you can
good session validation

doesn't matter whether the file is still there, doesn't even matter whether the cookie is still there, if your validation is good they can't get anywhere

[coopster]

!
What he said ;) To terminate a session the first thing I do is clear the $_SESSION superglobal array by initializing it. Then destroy the session. Don't forget, you always have to start the session first.

// session_name('mySession'); // if you have named your session 
session_start(); 
$_SESSION = array(); 
session_destroy();

Just that simple.

[yesmaster]

jatar_k,
thanks, I'm taking as many precautions as possible. About your list.. what constitutes good session validation?

[henry0]

Why not perform a double kill
A)unset()
B)destroy()

[coopster]

I never unset the whole $_SESSION superglobal as I may need it again during my script execution (highly unlikely, especially on logout, but I don't like destroying an entire system superglobal either). Rather, I initialize the $_SESSION variable by resetting it to a blank array. Think of $_SESSION as a placeholder and if you unset() the entire superglobal, you have just lost your placeholder. Best to just initialize it to an empty array. Here we go, I found the recommendation note in the manual:

Do NOT unset the whole $_SESSION with unset($_SESSION) as this will disable the registering of session variables through the $_SESSION superglobal.

[php.net...]

I've done some extensive testing and found the approach shown above to be most favorable. And in regards to the session_unset() function, here is a past discussion that may be of some interest:
[webmasterworld.com...]

[jatar_k]

>> what constitutes good session validation

well you could look at this thread for some ideas
[webmasterworld.com...]

you obviously set values in the session, you also know what those values/variables are. For your authentication you can make sure they are present, you can also check some of the values.

It all depends on what is in there

[henry0]

Agreed on

what I do (but could be wrong) is
I do not use it as session_destroy();
but this way:
session_destroy(S_SESSION['username']);

reason is that I REALLY need to see that session dying
at that level in my script

does this is as bad as your example?
if so how will you surely kill it?

[eelixduppy]

session_destroy(S_SESSION['username']);

The session_destroy function takes nothing as an argument, therefore this won't really work. What you can do, however, is unset the session variable:

[url=http://us3.php.net/manual/en/function.unset.php]unset[/url]($_SESSION['var']);

[henry0]

Thanks, never paid enough attention to it for I already do it (as you suggested in your example) to unset a session var

so since it worked fine I never thought about destroy() not taking an arguement
a bad case of not reading the manual in depth and taking stuffs for granted!

[cmarshall]

session_destroy(S_SESSION['username']);

The session_destroy function takes nothing as an argument, therefore this won't really work. What you can do, however, is unset the session variable:

unset($_SESSION['var']);

This is what I've been doing. Seems to work just fine, and you can always restart the session.

[yesmaster]

>> what constitutes good session validation

well you could look at this thread for some ideas
[webmasterworld.com...]

you obviously set values in the session, you also know what those values/variables are. For your authentication you can make sure they are present, you can also check some of the values.

It all depends on what is in there

Checked out the link you provided. I'm doing all of these, about your suggestion on keeping user's IP in a session: this would not work with many of my users. I've tried this before and a lot of them have providers that change their IP addresses frequently, event within 1 request. For example, just looking at server log, I'd have resources a.gif with referrer URL of aa.html (my own page) from IP 200.aa.bb.cc then in the same second, resources b.gif from reffer aa.html with IP 200.aa.bb.dd. So a lot of my users complained they were logged out in the middle of a session. The only thing reliable to stay constant is may be the first 3 blocks or 2 blocks of the IP address (200.aa.bb), not the whole IP address.

So I guess we could use that and some other unique stuff about the user like his browser string, ect...

[jatar_k]

that would work, the ip bit is always a bit dicey, some sites I have no problems, some I have nothing but

as you said, browser strings and the like are also pretty good

[FiRe]

If you are really worried about session files...

$path = "/path/to/sessions/folder/";

$files = array();
foreach ($_SESSION as $key => $value) {
$files[] = $key;
unset($_SESSION[$key]);
}

foreach ($files as $file) {
unlink($path . "sess_" . $file);
}

Haven't tested it but assuming you can access the session folder it should work. Also make use of session_regenerate_id() for session hijack prevention.

[edited by: FiRe at 3:56 pm (utc) on Feb. 23, 2007]

[henry0]

FiRe, I did not know about session regenerate
so I went to the manual
but it's not clear in my mind
at which level are you using the ()
where from is coming the added security?
thanks

[FiRe]

Session security works on the basis that the session ID is hard to guess. Not having to guess it makes thinsg easier.

PHP can accept session IDs through a cookie or URL.

Stealing sessions allows you to take over a logged-in user.

Session fixation means having a user follow a link with a provided session id in the URL. If they then login, you could connect with the session ID you provided and use their credentials.

Use session_regenerate_id() whenever a user logs in or changes their privilege level so an attacker cannot go back in and use the session id the provided to the target.

[henry0]

OK thanks got it
It seems a very good session management move.

Just wondering why it seems not to be a common practice

[yesmaster]

Thanks for all your input guys. I'm a C++ programmer but only been doing PHP on my own so it's great to get input from other practioners :)