By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,851 Members | 1,047 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,851 IT Pros & Developers. It's quick & easy.

need help with logout (logout not perfect)

P: n/a
Hi all,

I've written a login/logout code. It does what it's supposed to do but
the problem is when I logout and press browser's back button (in
Firefox), I get to the last login page. In IE, when I press back
button, I get to the page that says "Page has Expired" but Firefox does
not do this.

I think it's something to do with sessions not properly unset or
something like that but I haven't been able to figure it out. I am
attaching my codes and database structure below. If you need more info,
please email me. I really want this to be fixed asap. I've played with
this long enough. Thanks!

Login class:
-----------------

class Login {
//var $loginflag;
//var $db_connect;

function Login() {
//$this ->db_connect = $db_connect;

if (!isset($_SESSION['uid']) || $_SESSION['uid'] == 0) {
$this->set_session_defaults();
echo "inside login class<br />";
}
}

function check_login($username, $password) {
global $db;
$link=$db->connectDB();

if ($_SESSION['logged']) {
$this->check_session();
echo "logged...<br />";
return true;
} else {
$username = mysql_escape_string($username);
$query = "SELECT * FROM users WHERE username = '$username' AND
AES_DECRYPT(password, 'dreamfilmslogin438ismbtsx') = '$password'";
$result = mysql_query($query, $link) or die("Could not select");

if (mysql_num_rows($result)) {
$this->set_session($username = mysql_fetch_assoc($result), true);
return $username['username'];
} else {
$this->failed = true;
session_destroy();
return false;
}
}
}

function check_session() {
global $db;
$link=$db->connectDB();

$username = mysql_escape_string($_SESSION['username']);
$token = mysql_escape_string($_SESSION['token']);
$session = mysql_escape_string(session_id());
$ip = mysql_escape_string($_SERVER['REMOTE_ADDR']);

$query = "SELECT * FROM users WHERE username='{$username}' AND
token='{$token}' AND session='{$session}' AND ip='{$ip}'";
$result = mysql_query($query, $link) or die("Could not select");
echo "check session:<br />";
print_r($result);
echo "<br />";
if ($result != false) {
} else {
$this->logout();
}
}

function set_session_defaults() {
//session_start();
////session_register("logged", "uid", "username");
$_SESSION['logged'] = false;
$_SESSION['uid'] = 0;
$_SESSION['username'] = '';
}

function set_session($result,$init = true) {
global $db;
$link=$db->connectDB();

if ($init) {
//session_start();
$session = mysql_escape_string(session_id());
$ip = mysql_escape_string($_SERVER['REMOTE_ADDR']);
$result['token'] = $this->token(); // generate a new token
$query = "UPDATE users SET session='{$session}',
token='{$result['token']}', ip='{$ip}' WHERE uid='{$result['uid']}'";
mysql_query($query, $link) or die("Could not select");
$_SESSION['logged'] = true;
$_SESSION['uid'] = $result['uid'];
$_SESSION['username'] = $result['username'];
echo "set session:<br />";
print_r($result);
echo "<br />";
echo "session: ".$session."<br />";
echo "ip: ".$ip."<br />";
}
}

function token() {
// generate a random token
for($i=1;$i<33;$i++) {
$seed .= chr(rand(0,255));
}
return md5($seed);
}

function logout() {
global $db;
$link=$db->connectDB();

$query = "UPDATE users SET session='', token='', ip='' WHERE
uid='{$_SESSION['uid']}'";
mysql_query($query, $link) or die("Could not select");
mysql_close($link);
unset($_SESSION['username']);
unset($_SESSION['logged']);
unset($_SESSION['uid']);
// kill session variables
$_SESSION = array(); // reset session array
session_destroy();

/**$this->set_session_defaults();
session_destroy();*****/

echo "logged out...<br />";
return true;
}
} // end class Login

DBAccess class
-------------------------
class DBAccess {
var $_login;

// Constructor
function DBAccess() {
$this -_login = array();
$this -_login['db_loginid'] = "testuser";
$this -_login['db_password'] = "";
$this -_login['hostname'] = "localhost";
$this -_login['db_name'] = "dblogin";
}

function connectDB() {
if (!($link = @mysql_connect($this->_login['hostname'],
$this->_login['db_loginid'], $this->_login['db_password']))) {
echo "<strong>Could not connect:&nbsp;</strong>".mysql_error()."<br
/><hr size='1' /><br />";
} else if (!@mysql_select_db($this->_login['db_name'],$link)) {
echo "Could not select database";
}
if ($link) {
return $link;
}
} // end connectDB()
} // end class DB_Access
database structure
----------------------------
CREATE TABLE `users` (
`uid` int(11) NOT NULL auto_increment,
`username` varchar(20) NOT NULL default '',
`password` varchar(50) NOT NULL default '',
`token` varchar(100) NOT NULL default '',
`session` varchar(100) NOT NULL default '',
`ip` varchar(20) NOT NULL default '',
PRIMARY KEY (`uid`),
UNIQUE KEY `username` (`username`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=2 ;

Oct 30 '06 #1
Share this Question
Share on Google+
25 Replies


P: n/a
In article <11**********************@i42g2000cwa.googlegroups .com>,
<cr*********@yahoo.comwrote:
Hi all,

I've written a login/logout code. It does what it's supposed to do but
the problem is when I logout and press browser's back button (in
Firefox), I get to the last login page. In IE, when I press back
button, I get to the page that says "Page has Expired" but Firefox does
not do this.

I think it's something to do with sessions not properly unset or
something like that but I haven't been able to figure it out. I am
attaching my codes and database structure below. If you need more info,
please email me. I really want this to be fixed asap. I've played with
this long enough. Thanks!
Just curious what happens if you add these headers to the previous
pages?

( code from docs )

<?php
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past
?>

And this for the destruction of the session:

<?php
$_SESSION = array();

// Note: This will destroy the session, and not just the session data!
if ( isset( $_COOKIE[session_name()] ) )
setcookie( session_name(), '', time() - 42000, '/' );

// Finally, destroy the session.
session_destroy();
?>

--
Koncept <<
"The snake that cannot shed its skin perishes. So do the spirits who are
prevented from changing their opinions; they cease to be a spirit." -Nietzsche
Oct 30 '06 #2

P: n/a
>Koncept wrote:
Just curious what happens if you add these headers to the previous
pages?

( code from docs )

<?php
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past
?>

And this for the destruction of the session:

<?php
$_SESSION = array();

// Note: This will destroy the session, and not just the session data!
if ( isset( $_COOKIE[session_name()] ) )
setcookie( session_name(), '', time() - 42000, '/' );

// Finally, destroy the session.
session_destroy();
?>
No, still the same. I don't have any cookies set. I've only used
sessions in my code but anyway I tried all the above you have suggested
but there is no difference in the outcome. I hope someone can help me
with this.

If you want the codes, I can even email you the codes. Just let me know
by email. I really need to get this fixed.

Thanks

Oct 31 '06 #3

P: n/a
cr*********@yahoo.com wrote:
Hi all,

I've written a login/logout code. It does what it's supposed to do but
the problem is when I logout and press browser's back button (in
Firefox), I get to the last login page. In IE, when I press back
button, I get to the page that says "Page has Expired" but Firefox does
not do this.

I think it's something to do with sessions not properly unset or
something like that but I haven't been able to figure it out. I am
attaching my codes and database structure below. If you need more info,
please email me. I really want this to be fixed asap. I've played with
this long enough. Thanks!
No, Firefox has most probably pulled this from its cache. Disable the
cache (set to 0) and your problem will go away.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Oct 31 '06 #4

P: n/a
Koncept wrote:
In article <11**********************@i42g2000cwa.googlegroups .com>,
<cr*********@yahoo.comwrote:

>>Hi all,

I've written a login/logout code. It does what it's supposed to do but
the problem is when I logout and press browser's back button (in
Firefox), I get to the last login page. In IE, when I press back
button, I get to the page that says "Page has Expired" but Firefox does
not do this.

I think it's something to do with sessions not properly unset or
something like that but I haven't been able to figure it out. I am
attaching my codes and database structure below. If you need more info,
please email me. I really want this to be fixed asap. I've played with
this long enough. Thanks!


Just curious what happens if you add these headers to the previous
pages?

( code from docs )

<?php
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past
?>

And this for the destruction of the session:

<?php
$_SESSION = array();

// Note: This will destroy the session, and not just the session data!
if ( isset( $_COOKIE[session_name()] ) )
setcookie( session_name(), '', time() - 42000, '/' );
This line will never do anything. The session_name is the value of the
cookie, not the name. The cookie name is set in the php.ini file
(default: PHPSESSID).
// Finally, destroy the session.
session_destroy();
?>

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Oct 31 '06 #5

P: n/a
In article <nb******************************@comcast.com>, Jerry
Stuckle <js*******@attglobal.netwrote:
// Note: This will destroy the session, and not just the session data!
if ( isset( $_COOKIE[session_name()] ) )
setcookie( session_name(), '', time() - 42000, '/' );

This line will never do anything. The session_name is the value of the
cookie, not the name.
That's incorrect. session_name() will return the key (*PHPSESSID* )
which is then used as a key in the $_COOKIE superglobal to point to the
current session id.

http://php.net/session_destroy

You will notice that the code I provided you is directly from the PHP
docs and it is *not* incorrect.

As you can see from the example below, each time I start a new browser
session, I can, in fact, echo out what you suggest to be superfluous.
Perhaps the answer to your problem lies in this simple oversight unless
you have altered the value of "session.use_cookies" in your ini file.

<?php
session_start();

if(isset($_COOKIE[session_name()])){
echo $_COOKIE[session_name()];
}
// 72728376dfdd7f3de60f75111ace5a6e (first session - browser one)
// 1ce309fbb3bbdd0d34ed2b73be8cbe5b (first session - browser two)
?>

--
Koncept <<
"The snake that cannot shed its skin perishes. So do the spirits who are
prevented from changing their opinions; they cease to be a spirit." -Nietzsche
Oct 31 '06 #6

P: n/a
Koncept wrote:
In article <nb******************************@comcast.com>, Jerry
Stuckle <js*******@attglobal.netwrote:

>>>// Note: This will destroy the session, and not just the session data!
if ( isset( $_COOKIE[session_name()] ) )
setcookie( session_name(), '', time() - 42000, '/' );

This line will never do anything. The session_name is the value of the
cookie, not the name.


That's incorrect. session_name() will return the key (*PHPSESSID* )
which is then used as a key in the $_COOKIE superglobal to point to the
current session id.

http://php.net/session_destroy

You will notice that the code I provided you is directly from the PHP
docs and it is *not* incorrect.

As you can see from the example below, each time I start a new browser
session, I can, in fact, echo out what you suggest to be superfluous.
Perhaps the answer to your problem lies in this simple oversight unless
you have altered the value of "session.use_cookies" in your ini file.

<?php
session_start();

if(isset($_COOKIE[session_name()])){
echo $_COOKIE[session_name()];
}
// 72728376dfdd7f3de60f75111ace5a6e (first session - browser one)
// 1ce309fbb3bbdd0d34ed2b73be8cbe5b (first session - browser two)
?>
My mistake. But I'm not the one having the problem. And this code
doesn't solve his real problem - which is page caching in Firefox.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Oct 31 '06 #7

P: n/a
| Koncept <<
| "The snake that cannot shed its skin perishes. So do the spirits who are
| prevented from changing their opinions; they cease to be a
pirit." -Nietzsche

so, does this mean the absense of an opinion or the inability to change an
opinion make an apple cease to be an apple?
Oct 31 '06 #8

P: n/a
In article <11*************@newsfe06.lga>, Steve <no****@example.com>
wrote:
so, does this mean the absense of an opinion or the inability to change an
opinion make an apple cease to be an apple?
*Assertion* *1*: The absence of opinion makes an apple cease to be an
apple.

*Assertion* *2*: The inability to change opinion makes an apple cease
to be an apple.

*Answer*
If the apple were capable of formulating opinion in the first place,
then to lose such a noble quality would certainly make the apple less
distinguished amongst its peers; however, considering that the apple
never had such talent, it will simply continue to maintain its status
as an object neither capable of opinion, nor of spiritual nature.

Truth be told, I'd still eat it regardless!

Remember ... An a day keeps the doctor away.

--
Koncept <<
"The snake that cannot shed its skin perishes. So do the spirits who are
prevented from changing their opinions; they cease to be a spirit." -Nietzsche
Oct 31 '06 #9

P: n/a
In article <Fb******************************@comcast.com>, Jerry
Stuckle <js*******@attglobal.netwrote:
My mistake. But I'm not the one having the problem.
And it was my mistake (realized after posting the reply ) that you were
the original author. Sorry 'bout that.

--
Koncept <<
"The snake that cannot shed its skin perishes. So do the spirits who are
prevented from changing their opinions; they cease to be a spirit." -Nietzsche
Oct 31 '06 #10

P: n/a
So what's the solution??

I think disabling the cache in FF is not the real solution. Can't it be
done from the code itself? I've looked at some other login codes used
in opensource applications. They are basically using functions like
unset("session_name"). I am doing the same but for me it's not working.
I have no idea why it's not working for me.
Koncept wrote:
In article <Fb******************************@comcast.com>, Jerry
Stuckle <js*******@attglobal.netwrote:
My mistake. But I'm not the one having the problem.

And it was my mistake (realized after posting the reply ) that you were
the original author. Sorry 'bout that.

--
Koncept <<
"The snake that cannot shed its skin perishes. So do the spirits who are
prevented from changing their opinions; they cease to be a spirit." -Nietzsche
Oct 31 '06 #11

P: n/a
cr*********@yahoo.com wrote:
So what's the solution??

I think disabling the cache in FF is not the real solution. Can't it be
done from the code itself? I've looked at some other login codes used
in opensource applications. They are basically using functions like
unset("session_name"). I am doing the same but for me it's not working.
I have no idea why it's not working for me.
Koncept wrote:
>>In article <Fb******************************@comcast.com>, Jerry
Stuckle <js*******@attglobal.netwrote:

>>>My mistake. But I'm not the one having the problem.

And it was my mistake (realized after posting the reply ) that you were
the original author. Sorry 'bout that.

--
Koncept <<
"The snake that cannot shed its skin perishes. So do the spirits who are
prevented from changing their opinions; they cease to be a spirit." -Nietzsche

Nope, because Firefox is never going to your site. It's just serving
the page up locally.

You can set the page to expire immediately - but even that is only a
recommendation to the browser - not a requirement.

The only solution is to close the browser after logging off.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 1 '06 #12

P: n/a
>
Nope, because Firefox is never going to your site. It's just serving
the page up locally.

You can set the page to expire immediately - but even that is only a
recommendation to the browser - not a requirement.

The only solution is to close the browser after logging off.
So doesn't that mean my website is insecure? People can just go back
and access the pages inspite of being logged out. But how come lot of
other websites I have accessed are loggout out properly? That's why I
thought it's something to do with my code.

Nov 1 '06 #13

P: n/a
| "The snake that cannot shed its skin perishes. So do the spirits who are
| prevented from changing their opinions; they cease to be a
pirit." -Nietzsche

| *Answer*
| If the apple were capable of formulating opinion in the first place,
| then to lose such a noble quality would certainly make the apple less
| distinguished amongst its peers;

in what ways would it be less distinguished? doesn't this presuppose as a
foregone conclusion that to *be* an apple, it must emote opinion?

| however, considering that the apple
| never had such talent, it will simply continue to maintain its status
| as an object neither capable of opinion, nor of spiritual nature.

others may take your dismissal of the possible spirituality of nature - even
that of an apple - as a terribly imprompto assumption. either way, being
prevented from changing an opinion does not change the nature of the apple
itself were it able to formulate them. so, a snake may very well die if it
fails to shed its skin; it does not necessitate logically that a spirit not
able to, or prevented from, doing something/anything part of its nature
somehow removes the natural component altogether. the spirit remains a
spirit...as the apple is still an apple.

perhaps it is the fault of the translator rather than an illogical oversight
of neitzsche. where neitzsche consistent in his analogy and compared the
*death* of the spirit to the *perishing* of a snake, it would not be
illogical as it would be comparing two kinds of death - the first, literal;
the second, a deminished quality of life. as it is, he is comparing the
literal death of a snake to the alteration of the nature of a spirit
(assumably who MUST emote opinion) into some other form of being.

simply put...if a human is defined as such because of his ability to see,
can i take his eyes and make him non-human. or, if he must be social yet i
exile him to a desserted island...is he not still human? to be human is
merely to be engineered as such. neitzsche has engineered a spirit that can
hold opinion, but has sadly killed it off when no such requirement was
warranted.

| Truth be told, I'd still eat it regardless!

me too ;^)
Nov 1 '06 #14

P: n/a
..oO(cr*********@yahoo.com)
>So doesn't that mean my website is insecure?
No.
>People can just go back
and access the pages inspite of being logged out.
Of course they can go back in the browser history, but if they're logged
out they shouldn't be able to do anything on that expired page anymore.
>But how come lot of
other websites I have accessed are loggout out properly?
It's a common "problem", but usually nothing to worry about. When I log
into my webmail account to clean up my spam folder for example and then
log off, I can still go back in the browser's history. But if I then
click a link and try to access a protected page I get the message that
I'm no longer logged in.

Micha
Nov 1 '06 #15

P: n/a

Michael Fesser wrote:
People can just go back
and access the pages inspite of being logged out.

Of course they can go back in the browser history, but if they're logged
out they shouldn't be able to do anything on that expired page anymore.
In my case, when I press the browser's back button, it takes me to the
previous logged-in screen. In addition to that, the previous session,
token and IP are also stored in the database. I think this shouldn't
happen once the database is cleared of these entries when logged out.
Any thoughts?

Nov 1 '06 #16

P: n/a
cr*********@yahoo.com wrote:
>>Nope, because Firefox is never going to your site. It's just serving
the page up locally.

You can set the page to expire immediately - but even that is only a
recommendation to the browser - not a requirement.

The only solution is to close the browser after logging off.


So doesn't that mean my website is insecure? People can just go back
and access the pages inspite of being logged out. But how come lot of
other websites I have accessed are loggout out properly? That's why I
thought it's something to do with my code.
No, it's not insecure. It means they've just gone back to the browser
cache and displayed the page.

Just make sure all of your pages which you want to be accessed only by
logged on people are protected. Then any actions they take after
logging off (even if they go back to a previous page) will be rejected.

The only danger would be if they log off and leave (i.e. a public
computer) without closing their browser. In this case someone else can
come up and see your protected pages from the history. But there is no
way you can stop that.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 1 '06 #17

P: n/a
cr*********@yahoo.com wrote:
Michael Fesser wrote:
>>>People can just go back
and access the pages inspite of being logged out.

Of course they can go back in the browser history, but if they're logged
out they shouldn't be able to do anything on that expired page anymore.


In my case, when I press the browser's back button, it takes me to the
previous logged-in screen. In addition to that, the previous session,
token and IP are also stored in the database. I think this shouldn't
happen once the database is cleared of these entries when logged out.
Any thoughts?
Check this again and you will find you are mistaken here. When you
press the back button, everything is being done on the client. There is
no communication with the server.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 1 '06 #18

P: n/a
ive only had a brief look at the code, but if youre not careful, when
the browser sends an old session_id, it is possible for the application
to pick it up and run with it, using this old session_id as the basis
for new session data that as been removed.
This indeed is insecure as it does allow for people to press logoff,
and for your logoff method to be run, which at first glance appears to
remove the data in the table where session uid = the one they are
logged in as.
Then later (assuming the user presses back andsubmits a request which
includes the ookie headers with the value of the uid in it) the server
checks to see if the udi is present in the table which it is, just that
theres no data inside, the server then sets new data in the same row
and on they go.
maybe im barking up the wrong tree, but deleting the entire row seems
more prudent.
just my 0.02 and as I say - I only took a 20s look at the code so
apologies if this is just rubbish!
good luck.

Nov 1 '06 #19

P: n/a
In article <3G***************@newsfe04.lga>, Steve <no****@example.com>
wrote:
| "The snake that cannot shed its skin perishes. So do the spirits who are
| prevented from changing their opinions; they cease to be a
pirit." -Nietzsche

| *Answer*
| If the apple were capable of formulating opinion in the first place,
| then to lose such a noble quality would certainly make the apple less
| distinguished amongst its peers;

in what ways would it be less distinguished? doesn't this presuppose as a
foregone conclusion that to *be* an apple, it must emote opinion?

| however, considering that the apple
| never had such talent, it will simply continue to maintain its status
| as an object neither capable of opinion, nor of spiritual nature.

others may take your dismissal of the possible spirituality of nature - even
that of an apple - as a terribly imprompto assumption. either way, being
prevented from changing an opinion does not change the nature of the apple
itself were it able to formulate them. so, a snake may very well die if it
fails to shed its skin; it does not necessitate logically that a spirit not
able to, or prevented from, doing something/anything part of its nature
somehow removes the natural component altogether. the spirit remains a
spirit...as the apple is still an apple.

perhaps it is the fault of the translator rather than an illogical oversight
of neitzsche. where neitzsche consistent in his analogy and compared the
*death* of the spirit to the *perishing* of a snake, it would not be
illogical as it would be comparing two kinds of death - the first, literal;
the second, a deminished quality of life. as it is, he is comparing the
literal death of a snake to the alteration of the nature of a spirit
(assumably who MUST emote opinion) into some other form of being.

simply put...if a human is defined as such because of his ability to see,
can i take his eyes and make him non-human. or, if he must be social yet i
exile him to a desserted island...is he not still human? to be human is
merely to be engineered as such. neitzsche has engineered a spirit that can
hold opinion, but has sadly killed it off when no such requirement was
warranted.

| Truth be told, I'd still eat it regardless!

me too ;^)

Steve. I've got to say that I dig your style! I'm contemplating
changing my NG name to "spiritual apple" now.

--
Koncept <<
"The snake that cannot shed its skin perishes. So do the spirits who are
prevented from changing their opinions; they cease to be a spirit." -Nietzsche
Nov 1 '06 #20

P: n/a
| Steve. I've got to say that I dig your style! I'm contemplating
| changing my NG name to "spiritual apple" now.

you know, they say that it's all in the art of simplicity! the fact that i
have NO style would make me most likely to beat others in the
style-okham's-razor race. ;^)

i was just having fun with nietzsche. i have always found him to be highly
half-logical in making arguments, but at the same time very effective in
persuading one to them all the same. btw, out of all the good ideas that are
"The Dawn", what makes that one your favorite?
Nov 1 '06 #21

P: n/a
shimmyshack wrote:
ive only had a brief look at the code, but if youre not careful, when
the browser sends an old session_id, it is possible for the application
to pick it up and run with it, using this old session_id as the basis
for new session data that as been removed.
This indeed is insecure as it does allow for people to press logoff,
and for your logoff method to be run, which at first glance appears to
remove the data in the table where session uid = the one they are
logged in as.
Then later (assuming the user presses back andsubmits a request which
includes the ookie headers with the value of the uid in it) the server
checks to see if the udi is present in the table which it is, just that
theres no data inside, the server then sets new data in the same row
and on they go.
maybe im barking up the wrong tree, but deleting the entire row seems
more prudent.
just my 0.02 and as I say - I only took a 20s look at the code so
apologies if this is just rubbish!
good luck.
No, you can't go back and send the same session id (i.e. via a back
button) after you've destroyed it. The session information will no
longer be valid.

I haven't looked at the actual PHP code - but I've tried various
versions of this when testing security. Any data saved in the $_SESSION
is gone after calling session_destroy(), even if the same session is
sent again later.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 1 '06 #22

P: n/a

Jerry Stuckle wrote:
shimmyshack wrote:
ive only had a brief look at the code, but if youre not careful, when
the browser sends an old session_id, it is possible for the application
to pick it up and run with it, using this old session_id as the basis
for new session data that as been removed.
This indeed is insecure as it does allow for people to press logoff,
and for your logoff method to be run, which at first glance appears to
remove the data in the table where session uid = the one they are
logged in as.
Then later (assuming the user presses back andsubmits a request which
includes the ookie headers with the value of the uid in it) the server
checks to see if the udi is present in the table which it is, just that
theres no data inside, the server then sets new data in the same row
and on they go.
maybe im barking up the wrong tree, but deleting the entire row seems
more prudent.
just my 0.02 and as I say - I only took a 20s look at the code so
apologies if this is just rubbish!
good luck.

No, you can't go back and send the same session id (i.e. via a back
button) after you've destroyed it. The session information will no
longer be valid.

I haven't looked at the actual PHP code - but I've tried various
versions of this when testing security. Any data saved in the $_SESSION
is gone after calling session_destroy(), even if the same session is
sent again later.

thats not exactly what i said, in fact you can go into the filesystem,
and completely delete the session files themselves, and STILL resume
the session with the same id which recreates the same filename like a
phoenix from the ashes (have you tried that?) - the data wont be there,
but the session filename can be the same. and depending on how the
application stores the data, a partial or complete session can indeed
be resumed. It is unfortunate but nevertheless true.
Most so called "authentication" mechanisms are nothing of the sort and
simply rely on the session_id being an "authenticator" - thats how
session riding/hijacking works, and why you should be very careful HOW
you implement the code, rather than just sending a session storing info
in the session, and assuming that if someone has the session id they
are ok, and that once it has gone, that nothing can be resumed.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 1 '06 #23

P: n/a
>Nope, because Firefox is never going to your site. It's just serving
>the page up locally.

You can set the page to expire immediately - but even that is only a
recommendation to the browser - not a requirement.

The only solution is to close the browser after logging off.

So doesn't that mean my website is insecure? People can just go back
and access the pages inspite of being logged out.
All websites are insecure. People can go back and REMEMBER what
your page looked like after they've logged out. Or they could take
a picture of the monitor with a camera. Or save the page to a local
disk file. You won't be able to fix that until human brains are
required to support DRM so they can't remember anything beyond the
time limit in the license. Browser caches aren't much more of a
problem.

This does mean, though, that the only computers that have copies
of your stuff in the browser cache are those that had an authorized
user log in and view the pages in question.
>But how come lot of
other websites I have accessed are loggout out properly? That's why I
thought it's something to do with my code.
Don't use the presence or absence of a session cookie to indicate
that a user is properly logged in. Use data in the PHP session.
One method I think works well is to have a session variable 'last_hit',
which represents the time the session last hit the server (in the
protected section). You may also want another variable indicating
what user name they logged in with, so you know whose preferences
to use and whose name to use on sent messages.

You set this last_hit variable to the current time when they log
in correctly, (and remove it if they fail to log in) and check (on
every protected page) that it's not too old (say, no older than
half an hour). Don't use cookie expiration times; browsers don't
enforce them well, and desktop computers have notoriously inaccurate
clocks (once I discovered that 5% of certain users had the YEAR
wrong). Also don't use PHP session expiration times. If you read
the documentation you'll see that, in the name of performance, it's
really sloppy about cleaning up old sessions, especially if your
site doesn't get much traffic.

If they aren't logged in (last_hit not set) or it's too old, redirect
them to the login page instead of showing them the page they wanted.
If they ARE logged in and the session isn't stale, set last_hit to
the current time, then display the page. This permits users to
stay logged in as long as they want, provided they keep clicking.
If they go home from work, or otherwise walk away from the computer
for a long time, the session will go stale by the time they get
back. No matter how long it's saved in browser history, the
associated session data will show an *OLD* login, and they'll just
get the login page.

That limit for what constitutes a stale login requires some thought.
A year is probably too long. A second is way too short. A half an hour
may not be enough time for a user to compose a (thoughtful) message
and send it. Do you want to blow away a half-completed message if
they have to leave for lunch in the middle of composing it?

Nov 1 '06 #24

P: n/a
well said. defence against the dark arts is hard.
If you want to add to your session security and enforce even more than
the above, things like application-state-pathways, further
authentication for sensitive parts of the site, intelligent semi-trust
for certain users based on actions, restarting new sessions
transparently (including on login and logoff), sending the initial
session token over SSL and more, go ahead
This is a pretty good place to begin
http://www.owasp.org/index.php/PHP_Top_5
note the references there for further reading.
Sessions can be very tricky if you want things to be secure.
The more you read the more fun it gets.

Dont have nightmares, do sleep well

Nov 2 '06 #25

P: n/a
shimmyshack wrote:
Jerry Stuckle wrote:
>>shimmyshack wrote:
>>>ive only had a brief look at the code, but if youre not careful, when
the browser sends an old session_id, it is possible for the application
to pick it up and run with it, using this old session_id as the basis
for new session data that as been removed.
This indeed is insecure as it does allow for people to press logoff,
and for your logoff method to be run, which at first glance appears to
remove the data in the table where session uid = the one they are
logged in as.
Then later (assuming the user presses back andsubmits a request which
includes the ookie headers with the value of the uid in it) the server
checks to see if the udi is present in the table which it is, just that
theres no data inside, the server then sets new data in the same row
and on they go.
maybe im barking up the wrong tree, but deleting the entire row seems
more prudent.
just my 0.02 and as I say - I only took a 20s look at the code so
apologies if this is just rubbish!
good luck.

No, you can't go back and send the same session id (i.e. via a back
button) after you've destroyed it. The session information will no
longer be valid.

I haven't looked at the actual PHP code - but I've tried various
versions of this when testing security. Any data saved in the $_SESSION
is gone after calling session_destroy(), even if the same session is
sent again later.



thats not exactly what i said, in fact you can go into the filesystem,
and completely delete the session files themselves, and STILL resume
the session with the same id which recreates the same filename like a
phoenix from the ashes (have you tried that?) - the data wont be there,
but the session filename can be the same. and depending on how the
application stores the data, a partial or complete session can indeed
be resumed. It is unfortunate but nevertheless true.
Most so called "authentication" mechanisms are nothing of the sort and
simply rely on the session_id being an "authenticator" - thats how
session riding/hijacking works, and why you should be very careful HOW
you implement the code, rather than just sending a session storing info
in the session, and assuming that if someone has the session id they
are ok, and that once it has gone, that nothing can be resumed.
Sure you can. After all, the actual session ID is immaterial, other
than it be unique. When you start a session it could be the same ID or
a different ID. It really doesn't matter.

You should *never* rely on the session id. And quite frankly, I don't
know of any "authentication mechanism" which does. All I have ever seen
rely on information stored in the session. Besides - without the
session itself, how would one know if the session id is legitimate or not?

Session riding/hijacking is an entirely different thing, though. It
requires the hijacker to use the same session id as the legitimate user,
and that session to be still valid (not destroyed or timed out). PHP's
default session id is long and random - and virtually impossible to
guess in a reasonable amount of time. You'd have to be able to
intercept the cookie going through the network. And if someone can do
that, the only protection you would have would be using secure protocols.

Of course, some people implement their own session naming convention -
and don't do it in a secure enough matter. But that's their problem.
>


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


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Nov 2 '06 #26

This discussion thread is closed

Replies have been disabled for this discussion.