RE: [Phplib-users] Re: latest snapshot

[Richard A. <rh...@ju...>]

At 22:07 -0500 6/11/02, Rob Hutton wrote:

>  Not quite that simple.  Session cookies are never written to the hard
>drive and are not viewable from the cookie window.  The only way I can think
>of looking at them is by running the browser in a VM debugger and looking at
>the trace.  Even then I am not sure that you could find it because it might
>be scattered in the stack.

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.


>  It would be much easier to sit between the server and web site to do
>something, which is where https comes in.

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


>  Also, I asked a couple of questions on the Mozilla list, and to their
>knowledge, you would have to write some code to insert a session cookie into
>memory or attack the server directly without a browser (like with curl).

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.


>Either way is more trouble that simply entering a [session] id as a
>get variable, and is the safest way I see of doing it.

Yes, but if you have an attacker willing to try the non-trivial task of
session hijacking, presumably they have a reason driving them to do so.
In which case making it just a little harder might be giving yourself
and the user a false sense of security.

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.

Perhaps changing the session ID on each page view would be a better
approach. Wouldn't be too hard to implement either, I expect.

 ...R.