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

[Rob H. <rob...@ws...>]

> 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.

> 2. We should always try to avoid extra redirects - the main reason is
> that those redirects can be misunderstood by the search robots, and
> the site will not be properly indexed.

Most search tools ignore redirects as well as javascript, etc.  We are
talking about protected sites that people do not want indexed anyway.  If
they were for public consumption, then there would be no need to protect
them.

> 3. We should do something so that session hijacks could be made
> [almost] impossible. The old Session class has the same issue and the
> session can be hijacked using both PHPLib's Session3 and PHP4 session
> module weaknesses. The only way I see is to bind the session under some
> 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.

There is no good way of addressing this.  There are many papers, etc. on
doing so, but they are all at the protocol level and involve the user
posessing a personal key signed by a trusted third party.  When DNSSec
becomes more widely deployed, then there will be a reasonable way of doing
something, but not until then.

As it stands now, if the client has cookies enabled, then there is a fairly
secure way of tracking them.  If not, there is not a secure/reliable way.
That is the whole reason cookies were invented.  To store bits of data on
the client's machine because there was no reliable way of tieing it to them
next time.  How are you going to handle HP, which has a whole class B block,
but also has several thousand IPs behind masquerading machines.

The IP address can easily be forged.  It is called a man-in-the-middle
attack, and in this case, simply requires that you have a machine that is
behind the same proxy server or nat device to defeat this scheme.

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.

>
> So, the site with such restrictive policy could recommend cookies to
> everybody and enforce cookie usage by all users that may change their
> IP during the session.
>
>
>
> --
> Best regards,
> Maxim Derkachev mailto:max...@bo...
> IT manager,
> Symbol-Plus Publishing Ltd.
> phone: +7 (812) 324-53-53
> www.books.ru, www.symbol.ru
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phplib-users mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phplib-users
>
>