prevent session_replay

[Scott]

hi

I'm running PHP 4.2.3 as module with Apache 1.3.26 on OpenBSD 3.2 with the
chroot turned off (as it stopped the php_mail() funtion working, but if
anyone has the fix for that I will re-implement the jail again :o)

I'm having some problems with sessions. I am not using cookies, as many
people don't allow them to be set

The main page starts a session, takes username and password, and if they are
ok, it registers the users id from the db as a session variable using the
$_SESSION['user_id'] = $user_id

it then does a header redirect to another page, which at the moment for
testing just displays the SID and all $_SESSION[vars]

as the SID is being passed in the url, I am able to copy the http://url?SID
from the browser window

if I close the browser (which from reading the docs on sessions should end
the session) and then re-open another browser (admittedly on the same
machine/ip address) and post the http://url?SID back in, I get the page, and
the $SESSION[vars] are still there !!

it is reading them back out of the files in /tmp (if I edit these directly
and paste the url?SID in, I get the new values I mannually put in !)

:o( is there a official/approved method to prevent this from being done ?

thankyou

_scott

[Michael J. Pawlowsky]

It's called Session Hijacking.
And that is the normal behaviour.

Since you are supplying the session id it still thinks you are on the same session until it has expired. (expiry time set in php.ini)

Mike

*********** REPLY SEPARATOR ***********

>--
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php

[Marek Kilimajer]

This is how it works, but you can tie session to a specific IP (still
not 100% safe)

[Michael J. Pawlowsky]

The problem with that is, if you have a proxy farm you never know which IP might be used.
For instance, if the user is on AOL, every request to the server will probably have a different IP.

Mike

*********** REPLY SEPARATOR ***********

[Chris Shiflett]

Scott,

I think it is safe to say that there is no "official" way
to prevent session hijacking like this, nor is there any
way to provide absolute assurance that it cannot be done.
There are several methods, however, that can make a hijack
much more difficult to accomplish without adversely
affecting your legitimate users.

To get you going (since you are the best person to decide
what extra measures to take), consider that you could store
the user agent in a session variable. If you check that
variable on each page (many people include a common module
such as security.inc or session.inc at the top of each
script or use a parent script), it will at least prevent
your test of using a different browser. Of course, an
attacker can still hijack the session by passing the same
user agent (either by using the same browser or manually
sending the HTTP erquest), but the difficulty is a bit
more.

Your method of testing is actually a good one. The IP
address is a terrible metric for identification, so using
the same IP will prevent you from trying to use that to
distinguish good guy from bad guy. Just use your
creativity, and you will probably be fine. The goal is to
make things hard for the bad guys and easy for the good
guys.

Good luck.

Chris

--- "scott" <sc...@sporticia.com> wrote:
> as the SID is being passed in the url, I am able to
> copy the http://url?SID from the browser window if I
> close the browser (which from reading the docs on
> sessions should end the session) and then re-open
> another browser (admittedly on the same machine/ip
> address) and post the http://url?SID back in, I get
> the page, and the $SESSION[vars] are still there !!

> :o( is there a official/approved method to prevent