RE: [Phplib-users] Re: latest snapshot

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

> I would not expect any significant additional overhead on the server.
> You just need to generate a new session ID and change the database
> query which stores the session so that it updates the session ID when
> it stores the session variables. I wouldn't think there'd be more than
> about 10 lines of extra code in PHPLIB. Might be an interesting option
> to add sometime... have to make it optional via a local.inc switch!
>

Not with PHP4 sessions.  PHP itself controls the session ID.

>
> First time I've heard that... I would have thought cracking SSL
> connections in anything resembling real time without military-grade
> hardware would be big news. Got any pointers to how that's done?

There is a fairly easy MITM attack of up to version 2, which there is a lot
of still out there (anyone heard of IIS?).  I will try to drag out my docs,
I can't lay quick hands on them and it is time for a couple of hours of
rest.  Basically there was a weakness in the key exchange protocol that
allowed you to insert yourself into the stream anytime is you had recorded
the initial handshake.

>
>
> Except you don't get told what the cookie lifetime is. All you get back
> from the browser is the cookie name and value.

Right.  Guess that is a problem.

What about incrementing a separate random that gets changed in pageopen.
Call it sesscheck

start session
if ($_COOKIE['sesscheck'] != $_SESSION['sesscheck'] {
	//bomb out because we are being hijacked.
}
$sesscheck = md5(uniqid(rand(),1));
set_cookie($sesscheck)
$sess->register('sesscheck');

This would have a similar effect to changing the session id every time!!!!

>
>  ...R.
>
>