--- Scott Fletcher <[EMAIL PROTECTED]> wrote: > Or worse, not substituting the characters in the > Session ID. Just use the same Session ID. What if > there is leftover session file in the /tmp > directory of the Unix machine and we're dealing > with hundred of users each day. Some of those > session files aren't deleted because the user > just closed the browser without logging out. It > is unfortunate that there is no better solution to > this.
Actually, there is a better solution. Your observations are perfectly valid and correct. If the session ID is given complete trust (which is the case for many people, unfortunately, especially with the default configuration for sessions), then there are many security risks. Given your observations, I think you are on the right track to developing more secure state and session management mechanisms yourself. I am actually considering submitting a proposal to speak about this topic (well, Web application security with PHP in general) at OSCON and perhaps the PHP Conference coming in May. The reason that many people are hesitant to offer solutions is because no solution is perfectly secure. There are, however, many reliable methods you can use that will not adversely affect your legitimate users in any way and make life a bit harder for the bad guys. A common example I give just to get you going is that you can store the user agent in a session variable. While all Web clients may not send the User-Agent header, you can be assured that those that do will send the same User-Agent header for every request. Verifying this against the session variable can at least prevent the copy/paste from an email attack that you mentioned unless the attacker replicates the exact same User-Agent header. Anyway, you have very valid points. Hopefully I will get the chance to speak about this in more depth at a conference soon, and if not, I will probably at least write an article on it. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
