Posted by shimmyshack on 11/01/06 23:00

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

[Back to original message]