Posted by Jerry Stuckle on 11/02/06 12:34

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


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

[Back to original message]