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

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

> RH> I'm not following.  If the session doesn't have an IP then
> it's not valid?
> Right, it's not valid since it doesn't "exist" yet (in case when we
> always save client's IP, with every request). If we have a SID, but
> the session, associated with the SID is empty (or, at least, does not
> contain an IP, which should be there), than the most probably that the
> SID was hand-crafted or obsolete (the new session is born
> automatically), so we trash this SID and issue a new one, with a new
> session.
>
> RH> What if the IP doesn't match? Is it invalid also?
> This depends on your policy. I suppose, the "less evil" would be to
> close the session if the SID comes from anything but the cookie (we
> have 4 sources for SID in PHP). Cookie-enabled clients won't suffer.
> But the right way is of course to make this behavior turned on/off as
> desired.

So what you end up with is something that sounds good on paper, but causes
problems in MANY situations.  Can you imagine being the sysadmin and trying
to figure out why sessions just go away for SOME people, SOME of the time?
AHHHHH!!!! It is going to have to be turned off for anything over the
Internet at a minimum, and also for anything in large corporations, as they
also use NAT, and provides a false layer of security.

>
> RH> Most search tools ignore redirects as well as javascript, etc.  We are
> RH> talking about protected sites that people do not want indexed
> anyway.  If
> RH> they were for public consumption, then there would be no need
> to protect
> RH> them.
> Wrong. Tell this to Amazon :) The public sites must be protected, if
> they are not going to loose their clients.

Um, I just went through this on three different sites.  DMOZ refused to list
them until there were no script tags in several pages that used javascript
for navigation.  In the rules that they sent me, Exite, Google, Alta Vista,
and I don't remember who all that use them now do not transverse to pages
based on Javascript, Header redirects, and META redirects.  They require you
to have a script block that the robot uses transverse.

The Amazon thing is a completely different situation.  You can go to Amazon
and browse a tremendous amount of their site without ever logging in.  The
rest is addressable with a robots.txt and good security structure.

>
> RH> There is no good way of addressing this.  There are many
> papers, etc. on
> RH> doing so, but they are all at the protocol level and involve the user
> RH> posessing a personal key signed by a trusted third party.  When DNSSec
> RH> becomes more widely deployed, then there will be a reasonable
> way of doing
> RH> something, but not until then.
>
> We live just now. And when somebody can snoop into your personal
> details without any serious effort, the problem should be solved.

If it is this serious, then none of this should be used.  It is trivial to
pull a cookie from the browser cache.  We had a conversation on the list
about this several weeks ago.  If it is sensitive, then use HTTPS and
require cookies.  There simply is no in between at this point.

>
> RH> As it stands now, if the client has cookies enabled, then
> there is a fairly
> RH> secure way of tracking them.  If not, there is not a
> secure/reliable way.
> RH> That is the whole reason cookies were invented.  To store
> bits of data on
> RH> the client's machine because there was no reliable way of
> tieing it to them
> RH> next time.  How are you going to handle HP, which has a whole
> class B block,
> RH> but also has several thousand IPs behind masquerading machines.
>
> I do know about proxies and masquerading. I also know that a dialup
> users often receive a different IP after reconnect. But we should
> decide what should be more secure way - to let everybody take over
> someone else's session or restrict them. We can not make all the
> people to use cookies.

Yes, but it is not doable at this point.  I ask that you do a little bit of
research and read several of the papers on this very subject before delving
into a solution.  This IP scheme has been tried and does not work.  Look at
all the problems with deploying IPSEC.  Even if the endpoints are
interoperable, then it still does not work a lot of the time because the end
points are masqed.  And that is without the ISPs trying.

>
> RH> The IP address can easily be forged.  It is called a man-in-the-middle
> RH> attack, and in this case, simply requires that you have a
> machine that is
> RH> behind the same proxy server or nat device to defeat this scheme.
>
> Yes, but if we have a man in the middle, all the efforts are useless -
> he can simply sniff our traffic. Cookies won't save us, only SSL will.

Right.  So require cookies and SSL on personal or sensitive information.
Put that in the docs with the reasons why and call it quites.  Do not
provide something that is a false sense of security.

>
> RH> I vote that the documentation cover the security aspect, and
> leave it at
> RH> that until there is a widely deployed public key system that can be
> RH> leveraged instead of trying to invent something that provides
> an artificial
> RH> sense of security and will cause problems.
>
> We don't invent something - look at Amazon, again. They are always
> provide SID in the URLs, but I've never heard that they are
> vulnerable. They don't use pubkeys, they have their pages perfectly
> indexed by robots, and they deal with the problems, somehow. Try to
> access their pages with someone else's SID. We can endlessly discuss
> the theoretical matters, but we live now and should deal with this
> now, somehow, and should not wait for someone with the magic wand, I
> suppose.

Try turning cookies off and accessing Amazon.  Try buying from them with
cookies off.  Try turning SSL support off and doing so.  Now try
reconnecting, making sure you have a different IP, and refreshing.  They use
session cookies.  They check protocol and they make sure the get and the
cookie match.  The reason that the get is there is for historical reasons #1
and for ease of passing the session to other sites.

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