need help with logout (logout not perfect)

[crescent_au@yahoo.com]

Re: need help with logout (logout not perfect)


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?

[Jerry Stuckle]

Re: need help with logout (logout not perfect)

crescent_au@yah oo.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
>>recommendatio n 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.
jstucklex@attgl obal.net
=============== ===

[Jerry Stuckle]

Re: need help with logout (logout not perfect)

crescent_au@yah oo.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.
jstucklex@attgl obal.net
=============== ===

[shimmyshack]

Re: need help with logout (logout not perfect)

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.

[Koncept]

Re: need help with logout (logout not perfect)

In article <3GW1h.401$q06. 166@newsfe04.lg a>, Steve <no.one@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

[Steve]

Re: need help with logout (logout not perfect)

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

[Jerry Stuckle]

Re: need help with logout (logout not perfect)

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.
jstucklex@attgl obal.net
=============== ===

[shimmyshack]

Re: need help with logout (logout not perfect)


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 "authentica tor" - 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.
jstucklex@attgl obal.net
=============== ===

[Gordon Burditt]

Re: need help with logout (logout not perfect)

>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
>recommendati on 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?

[shimmyshack]

Re: need help with logout (logout not perfect)

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

[Jerry Stuckle]

Re: need help with logout (logout not perfect)

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 "authentica tor" - 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 "authentica tion 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.
>>jstucklex@att global.net
>>============= =====

>
>

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