Dan Hardiker wrote: >>It is also very conceivable that a person would send a link to a java >>applet or any other kind of wrapper (PHP or other CGI actually would be >>able to establish the connection on the server side always sending the >>same user agent string and sending back the data from your site) to >>establish the session in which case this is rendered useless. >> > >So because its not flawless, we shouldnt try to get as close to perfection >as we can? > >I know its not water-tight by any stretch of the imagination, but the more >checking in there, the harder it is for hackers to get the foot in the >door and penetrate. The more abstract the system is (especially on a site >by site basis) the more work a cracker has to do to work out how a host is >authenticated. >
To me this thread has two main issues: 1) don't false advertise: I agree that most of these methods are good steps in the right direction, but it's also important (IMHO) to not label them as 'completely secure'. I think that is misleading. Labeling them as 'good', 'better', 'best available' is swell (and should be done - people need to know the best course of action), but none of them are perfect, and it's important to note that. 2) False-positives suck: Validating session auth based of ip or user_agent permanency will simply not work. People coming from places like AOL will light up your logs with warnings about potential session hijacking. To me, this is really bad. It clutters the logs with a lot of false-positive security violations, making it even harder to detect the real ones. We tried user_agent matching at my last shop. We were getting 10-20 alerts a second while we had it on. Largely from aol. George -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
