Re: [Phplib-users] new Session4 changes

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

  > Maxim Derkachev wrote:
  >
  >> =C7=E4=F0=E0=E2=F1=F2=E2=F3=E9=F2=E5, Giancarlo,
  >>
  >> The old PHPLib's Session class is damn slow compared to the native P=
HP4
  >> sessions.

I think that comes from the save_handler most of all

  >> 1. The check for session existence is trivial. In my addition to the
  >> Session4 the session exists if the originator's IP is registered wit=
h

Why not 'preissue' a fair enough number of 'second_half of session
info', and save them in the session, so  that only one among those can
be appended or cookie_appended? Use once
random md5 digests. Would that  be really bullet_proof..


  >> the session. If we have a SID in the request and don't have *any* IP=
 in
  >> the session, the session does not exist, so the SID should be
  >> omitted and the new session with the new random SID should be emitte=
d.


  >> 2. We should always try to avoid extra redirects - the main reason i=
s
  >> that those redirects can be misunderstood by the search robots,

This problematic is really at the opposite of the one regarding privacy
and hijacking. That's why you may want more mutations, and more fallback
paths, depending on the situation. Afterall if you have private areas
accessible from anything between cookieless_always_authenticated and
cookie_only_always_reauth (or any mix), and also want robots to sneak
around safe, you need possibility to mutate the policy in different ways=20
for the cases, no one can fit all.


and
  >> the site will not be properly indexed.
  >> 3. We should do something so that session hijacks could be made
  >> [almost] impossible. The old Session class has the same issue and th=
e
  >> session can be hijacked using both PHPLib's Session3 and PHP4 sessio=
n
  >> module weaknesses. The only way I see is to bind the session under s=
ome
  >> circumstances to a marker that can not be forged. The only such a
  >> marker I see is the user's IP address - the others can be easily
  >> rewritten in the request variables. Given that the cookie is one of =
the
  >> hardest thing to forge (just because the nature of the attack - the
  >> attacker tries to persuade the victim to click an URL), we can ease
  >> the restrictions for cookie users.
  >>
  >> So, the site with such restrictive policy could recommend cookies to
  >> everybody and enforce cookie usage by all users that may change thei=
r
  >> IP during the session.
  >>
  >>
  >>
  >
  >