|
|
Posted by Jerry Stuckle on 11/01/06 22:03
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@attglobal.net
==================
Navigation:
[Reply to this message]
|