Re: [Phplib-users] Sessions where are we going??

[Giancarlo <gia...@na...>]

> > Donncha O Caoimh wrote:
> > > Take a look at this site, which I linked to from my howto last week, it
> >
> > should
> >
> > > help solve some of the security issues with php4 sessions.
> > >
> > > http://www.webkreator.com/php/configuration/php-session-security.html
> >
> > It is interesting, and in facts it clearly states that with auth, the
> > session is better handled by phplib rather than PHP4.
>
> I'm not certain what you mean by that.. but I'm satisfied by what he says

It was in facts Tarique's  doc, linked from there, that says that, at
http://www.sanisoft.com/phplib/manual/php4_sessions.php
and I fully agree.

   << If you want to use phplib's auth, perms or user variables, it is better
        not to use PHP4's session functions, but only phplib's >>


Gian


> that all reasonable measures can be taken to avoid letting a web based user
> take over a session. (BTW - your idea about cloning a session after
> authentication? excellent.. I wonder if hotmail do something similar when
> they reload their pages several times on login?)
>
> > I found there is a workaround to force cookie_only in php4:
> > defining php.ini
> > session.referer_check='someimpossiblestring'
> > or something, which can force cookies all over in php4, but not on links
> > clicked within an email, 'vause they have no referer.
> >
> > > Basically, each vhost gets its own directory, and even session name.
> > > That should help to stop people stealing sessions from one vhost to
> > > another. If you can chmod 700 and chown nobody:nobody the directory
> > > then local users can't inspect those directories (unless they look at
> > > them through a script running as nobody of course but the same applies
> > > to using a db as a backend, almost)
> >
> > But any other vhost can run a php a script that browses there
>
> I know, but they can also run a php script that can access the database and
> read the session data from the db. I honestly think there's only so much
> you can do before the return on investment on time becomes minimal. You
> could probably only guarantee security if you allow each user to run in a
> chrooted environment where they can only see their own db, their own few
> directories.
>
> umm.. d'you want this to go to the list? I'll resend there (without this
> paragraph) if you do.
>
> Donncha.