RE: [Phplib-users] Re: latest snapshot

[Rob H. <rob...@ws...>]

Interesting idea about changing the session ID.  I don't see any kind of
session_replicate and if you change the id manually, you loose everything.
I would think this could get to be a serious amount of overhead on the
server, too.  Anyway, here is the relevant paragraph from the PHP manual:

***
Sessions rely on the session ID, meaning one can 'steal' a session, by
stealing the session ID. This can be made harder, by using a cookie
specifically a session cookie, but does not in any way make it impossible
and still relies on the user closing all browser windows, to expire the
session cookie. Besides that, even session cookies can be sniffed on a
network or logged by a proxyserver.
***

So, the trick is some end user responsibility (close all windows) across SSL
and strong session IDs.  Maybe a disclaimer should be added.  Also, should
the length of the session ID be extended?

Someone in the manual suggested storing the IP of the remote machine in the
session and refusing to start it if the session request comes from somewhere
else.  Problem is, inconsistent browser support, implementation, and proxy
server farms.  Maybe in "SUPER DUPER SECURITY MODE".

Other responses in line.

>
> Might be. Or you might be able to run a memory search tool, search for
> the cookie name and see the value right next to it. Finding the cookie
> name is trivial... just load the site on another computer with "prompt"
> for cookies and it'll tell you.

But this requires physical access.  It would be easier in most environments
to do it across the net.  Plus, it's the old rule of turn you screen saver
on with a password so that someone does not come up to your machine and use
it while you are not there.  This is a physical security issue.

>
>
> Yup. If you want even a veneer of security, run the session over SSL.

Except SSL isn't that hard to crack ;-)

>
>
> No need to insert a session cookie into the browser's runtime state.
> Quit the browser, add a permanent cookie to your cookie jar with a text
> editor, start the browser, load the URL. There is no inherent
> difference between a permanent cookie and a session cookie except that
> the browser caches them differently.

So the cookie lifetime should be checked to make sure it is 0.  Will add to
my mods to auth.

>
>
> The only drawback I can see of GET strings is that perhaps the Session
> ID can be obtained by reading the target's screen (i.e. with a
> telescope through a window, with a hidden camera etc). I see this as
> only a minimal drawback over the cookie approach, and if session
> hijacking is of concern, cookies are IMHO not an adequate security
> mechanism in themselves.

Or the age old shoulder surfer.  That's how a lot of passwords are
compromised to this day.  If it is on the screen, someone can walk up behind
the user and see it, write it down, etc.  Most stuff like this is much more
intimate than a telescope.  You'd be surprised how many "high" security
areas that I have gotten into during physical audits by pushing around a 50
gallon trash can on wheels with some cleaning supplies on the outside.  I
had someone let me in to a Level 3 (top) security government contractor by
telling them I was new and had not gotten a badge yet.