Re: [PHP4BETA] Session Cookies With External Reference Checking Not Working; Patch Attached

Hi, Sascha, Sascha Schumann wrote: > > Andreas, > > On Mon, Feb 28, 2000 at 09:14:31AM -0500, Andreas Pour wrote: > > > > Hi, > > > > Using cookies with external reference checking is broken. Actually, > > Patch level 1 of PHP4 has all session-cookie checking broken if you set > > session.referer_check to 0 in php.ini, this patch fixes the problem: > > You disable session.referer_check by assigning it the empty string. Ahh, I see. I take it from this and the example below that in fact the session.referer_check should contain the name of the domain of the host site. Unfortunately, the document doesn't say that, and worse, says it defaults to '0' rather than "" (which is quite confusing given the number of binary switches). > > > It's not clear to me why you are looking at HTTP_REFERER. The relevant > > No. REMOTE_ADDR can change (cascaded proxies). How common is that? Even with cascading proxies, doesn't the client generally follow the same route? There may be some sites where there is some dynamic load-balancing going on for client requests, but I guess I don't have a feel for how common this is. > referer_check > is there to check HTTP_REFERER. It's useful, if site A points > to site B using an URL which contains a session id. That > sometimes happens, if a user copies the plain URL including > the session id and puts it on his/her homepage. referer_check > will reject the session id then. Right, but much more likely the user will send the link in an e-mail. Or even if it's on a homepage, anyone with a bit of knowledge of php will know to cut and paste to exploit the security hole, rather than click; and in any event home-page type changes would generally occur after the session has expired anyway. In other words, I really don't think this offers much protection. It's much safer to check originating IP numbers, those are much harder to spoof than it is to defeat an HTTP_REFERER check. On this note, it might be a nice feature to permit users to configure, so those very few that use some sort of dynamic proxying could elect to disable the security feature whereas everybody else can take advantage of it. This would only require a run-time directive to enable/disable REMOTE_ADDR checking. The referer check you describe also seems too broad. Say I have a family of sites with cross-linking -- e.g., www.mysite.com and devel.mysite.com and ftp.mysite.com. If I click from a link in www. to one in ftp., even w/out an SID get field, my cookies will cause my session to end, and I probably will not know why I just lost all my data. I guess permitting wildcards in the referer_check field would ameliorate this problem. But you still have the problem of the same person in the same session who already has a window open on my site clicking in from another link to my site, and let's say the SID is in a cookie rather than the URL, in which case an otherwise legitimate click back in would not only prevent the new window from sharing the same session as any other window, but the other open windows would have their session terminated! So, with all due respect, I stick to my view that HTTP_REFERER is the wrong way to go. Ciao, Andreas