[imp] wrong person's inbox?

[Miroslaw Jaworski]

* Jie Gao (J.Gao at isu.usyd.edu.au) [021018 10:15] wrote:
> > > > > > We had a user report that he signed in read his email, signed
> > > > > > out, then signed back in again and was presented w/someone else's
> > > > > > mailbox.
> > > > >
> > > > > It has come up before but none of the reporters was actually able to
> > > > > reproduce it. It always have been end user reports.
> > > > > You use session.entropy correctly, don't you?
> > > >
> > > > I *think* I've entropy set up correctly.  Here are the settings from our
> > > > php.ini
> > > > file:
> > > >
> > > >     session.entropy_length = 16
> > > >     session.entropy_file = /dev/urandom
> > > >
> > > > Are these values right?  Do I need additional settings?
> > >
> > > No, looks good.
> >
> > Is the random session number the only thing protecting user session?
> >
> > I know that 16^16 gives quite a big set, and if one thinks it's not
> > enough one can simply increase entropy_length, significantly lowering
> > the probability of "same sid generation" case.
> >
> > But - rare user reports about "hijacked sessions" may be a signal,
> > that random session numbers are too weak protection.
> 
> I still had report of the problem from end users even when I increased
> session.entropy_length to 32. We are on 64 now, and I haven't heard back
> from these users again.

You must have very busy site ( can you provide some numbers ? - maybe
it is the crucial point here ).
   
For the first - your case may be the case when session number is not
generated in the ideal way ( eg. when conducting huge number of the session
number generation tests you'll see unequal generated number propagation   
among whole set ). Thus - the probability of giving same "random"
session number for two user can be much more bigger than theoretical
possibility resulted in ideal random generator use.

No matter how good or bad random session number generation routines are,
there is a way to tighten sessions security and avoid "session hijacking"

>From your observation it looks like IMP just goes with delivered SID - checks
its sessions structure looking for specified SID, and if it exists
( session is active ) - what is the loginname of the user using it
( of course it checks also the time, compares with allowed idletime,
and eventually logs out the user ). In this way IMP knows which mailbox
to show. In this case seeing another user mailbox is as simple as
specyfiying existing session in url.

Let's look at the different scenario:
- sessions structure ( stored in sql table or regular files )
  stores not only session number, but also:
  - X-Originating-IP
  - REMOTE_HOST
  - HTTP_USER_AGENT
  - current URL
  - any other user/session specific params that can improve our checks
    quality
- every time application gets a request, it checks not only if delivered
  SID is correct ( eg. sid number exists in sctive session numbers listing ),
  but also validates it against additional data:
  - is X-Originating-IP same as previous
  - is REMOTE_HOST same as previous
  - is HTTP_USER_AGENT same as previous
  - is HTTP_REFERER same as stored URL ( previous location requested by user )
  - any other implemented
- if validation succeeded, it performs its usual actions.

I dont know if this scheme is implemented in IMP. Your observations
suggests, it's not.

Regards

MJ.

-- 
Miroslaw.Jaworski at ipartners.pl  ( Psyborg )  MJ102-RIPE  Internet Partners
Server Administration Department Manager