RE: [Phplib-users] Re: latest snapshot

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

Sorry, entering a session ID as a get variable, not uid.  I'm getting ahead
of myself!!!

> -----Original Message-----
> From: php...@li...
> [mailto:php...@li...]On Behalf Of Rob Hutton
> Sent: Wednesday, November 06, 2002 10:07 PM
> To: Richard Archer; php...@li...
> Subject: RE: [Phplib-users] Re: latest snapshot
>
>
>   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
> >
>
>
>
>
> -------------------------------------------------------
> 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
>
>