RE: [Phplib-users] Re: latest snapshot

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

  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.
  It would be much easier to sit between the server and web site to do
something, which is where https comes in.
  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).
Either way is more trouble that simply entering a uid as a get variable, and
is the safest way I see of doing it.

Thanks,
Rob Hutton
Web Safe
www.wsafe.com

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Richard
> Archer
> Sent: Wednesday, November 06, 2002 5:33 PM
> To: php...@li...
> Subject: RE: [Phplib-users] Re: latest snapshot
>
>
> At 16:19 -0500 6/11/02, Rob Hutton wrote:
>
> >  If you allow the session ID to be passed in as a string, then
> someone can
> >hijack a session by simply passing the session ID in the get string.  A
> >cookie is much harder to insert, and since they are session cookies, they
> >can't easily be viewed or replicated...
>
> OK. It is trivial to insert a cookie once you know the values. You
> can edit your cookie file with a text editor or use curl to pass in
> the cookie on the command line.
>
> So, session ID discovery is really the key here.
>
> If physical access is available, concealing the session ID is
> meaningless because the perp can sit at that machine and continue
> the existing session just as easily as they could copy down the
> session ID from screen or run a memory scanning utility to find it.
>
> Without physical access to the user's machine, session hijacking
> requires sniffing the traffic to determine the session ID... in
> which case the GET string and the cookie would both be displayed
> as plain as day.
>
> However I would assume that if security is any sort of an issue
> then the session would be running over SSL in which case it is not
> a trivial matter to obtain either the GET string or the cookie and
> in this case I can't see why one should be preferred over another.
>
> But I must admit I've never studied this area in great depth.
>
>  ...Richard.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>