>> 2) Cookie security, so user1 can read user2's cookie files > > Something like above, but cookies are not files as I'm sure you know ;) > (though they are stored somewhere, this is just implementation). They are stored in files, by default, though you can put them in a database, or whatever you want. >> 3) Malicous user2 filling up everybody's /tmp dir with zillion cookie >> files >> >> #1 is a non-problem, almost for sure. I don't think the OS+PHP will >> *ever* let your cookie files share a common name >> >> #2 separating them into different directories is not a whole lot of >> help... If I know his cookie files are in ~/user2 and follow the same >> naming conventions as the ones in my ~/user1 directory, I can still read >> them. > > I'm talking about COOKIE PATH - Path parameter of Set-Cookie header. > What should user1 do in order to separate his cookies and sessions from > other users is to give them different cookie path: > > session_set_cookie_params(0, '/~user1/'); > session_start(); > > But malicious "evil" can do: > > session_set_cookie_params(2147483647, '/~victim/'); > session_start(); > > Then write a script that will periodicaly check > http://server/~victim/?SESSIONID=' . $stored_session_id if it displays > Hello Richard (or any other sign off being logged in, eg log off link) > and the session is highjacked. They don't have to muck around with session_set_cookie_params() to do that. They can just read the Cookie files, or database, or whatever. You have a chicken and egg problem here: Either PHP can read the cookies from wherever, and so can the malicious scripter, or PHP can't read the cookies, and, well, you don't have cookies. >>>Each user should use session_set_cookie_params() to set the cookie path >>>to its own directory. And use of session_regenerate_id() is a must, else >>>user1 can set the cookie path to /~user2/ with lifetime till 2038 and... >> >> >> And what? >> >> Until we know what it is you think you're trying to "solve" we can't >> advise you. > > unique session for each user directory (/~user) and SECURITY. I think > this was the concern of the OP. SECURITY is not an on/off switch. There is no feasible way (in general) for script X from user X in PHP to not be able to read anything script Y from user Y can do in PHP on a shared server. If you *NEED* that level of SECURITY, don't use a shared server. Period. If you want to make it slightly more difficult, or at least less obvious, you could put user X cookies in their database, and user Y cookies in a different database. Of course, now you have the issue that if user Y *wants* to badly enough, they can read use PHP to read the file that has the password that user X uses to connect to their database, and then they can get to the data. >> So far, all we've got is a stated desire to segregate cookie files for >> no >> apparent reason. >> >> I'm sure it's perfectly clear to you why you want this, but nobody else >> is >> getting it. > > I hope everyone gets me now. Somewhat. The problem is that you've focused in on "Cookies" in a shared-server environment, when, in fact, the security levels implied in that shared-server environment have much more far-flung effects and implications that render your "Cookie" fixation rather meaningless. Basically, if you *NEED* that level of separation of Cookie files, then they shouldn't be on a shared server, because of everything *else* they are already sharing. Hope that makes sense. Some other options, however, do include: Give EACH user their own HTTPD pool of servers, running as some user such as 'victor-www' with a different user for each. Then all their files can be 600 or 700 and their Cookies as well. This doesn't scale up well for lots of users on a single server, which is a business requirement for most shared servers. But it may be the Right Solution for what you need. Hide their Cookie files in intermediate directories whose names are difficult to guess and which are NOT eXecutable (list-able) by other users. The Malicious user could still, eventually, manage to find the file somehow, perhaps by using PHP to read PHP source code and settings rather than reading the file structure itself. Synopsis: You are, most likely, zooming in too focused on Cookie files, and either have MUCH bigger issues of SECURITY, or are just wasting your energy on a tiny portion of a problem you simply cannot "solve" in the manner you are attacking it. It's also possible, though extremely unlikely, that you have a very weird, rare, specific problem to solve, but without telling us more, will only get useless generic answers that won't help in the least. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
