Re: Re[2]: [Phplib-users] new Session4 changes

[Kristian K. <kr...@ko...>]

On Mon, Dec 02, 2002 at 10:04:15AM -0500, Rob Hutton wrote:
> > 1. The check for session existence is trivial. In my addition to the
> > Session4 the session exists if the originator's IP is registered with
> > 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 emitted.
> 
> I'm not following.  If the session doesn't have an IP then it's not valid?
> What if the IP doesn't match? Is it invalid also?  This simply will not
> work.

Using this post to plug into this discussion.

Amending your reasoning:

Sessions must not work with IP numbers at all. Anything within a
session that uses IP numbers for other purposes than loggin is
broken and will never work correctly in general. There are very
limited usage scenarios where this may be different, but they
have to be justified in each and every case for correctness.

This topic has been coming up repeatedly on the old PHPLIB
mailing list and discussed to death. The summary:

1. Multiple users with different sessions may come from the
   same IP number.

This is always the case when these users work on a multi user
machine. It is also the case when multiple users are using the
same proxy server.

2. A single user may have an ongoing session, but subsequent
   requests from this session come from different IP numbers.

This is always the case when the proxy the user is on is in fact
a load balancing cluster. It is also the case when the user is
on a dialup, disconnects and reconnects due to an idle timeout.

Both cases are observed simultaneously for all users on German
T-Online (~6*1E6 users using a proxy cluster with some dozen IP
numbers) and all AOL users. These users are always using a
proxy, and that proxy is load balanced, establishing a true n:m
cloud between sessions and IP numbers.

This makes anything that uses IP numbers useless, even without
taking spoofing or other attack modes into account.

> > 3. We should do something so that session hijacks could be made
> > [almost] impossible.

Yes, there is one single way to do this. 
Use SSL.
Everything else is just pixie dust.

> I vote that the documentation cover the security aspect, and
> leave it at that until there is a widely deployed public key
> system that can be leveraged instead of trying to invent
> something that provides an artificial sense of security and
> will cause problems.

Correct strategy.

Also, using SSL will fix many of these problems today, using SSL
with client side certificates does fix all of these problems
today. The PKI is in place, you just have to distribute the
certificates.

Kristian

-- 
http://www.amazon.de/exec/obidos/wishlist/18E5SVQ5HJZXG