On Sat, 23 Jan 2010 15:10:11 +0000, nrixham@xxxxxxxxx (Nathan Rixham) wrote: ................................ > >To answer your specific questions though - what can be done to make this >process more secure - no matter what approach you take, when working via >http and needing logged in / secure functionality; you need the client >to identify themselves with a key of some sort - no matter how you make >the key it's always going to be passed via http (GET/POST/COOKIE) - if >some "hacker" passes the same key then your system is going to think >it's the original user and give them access. > >To make it trickier you can store information such as the users IP >address, user agent string etc in session and compare it on each >request; if it changes log the user out and destroy the session data - >however your never going to protect against the most common form of >"hacking", a nosy co-worker / person in the same house having a nosey >while the user is at the toilet / making a brew. This is why many sites >re-request password confirmation for potentially sensitive actions like >transferring money, changing personal details and so forth (and send >email confirmations to tell the user what changed - just in case). > >It must be pointed out though that non of this is worth even considering >if you have sensitive ports (like ftp/ssh/mysql) open to the outside >world as it's these back doors people will use to hack the whole server, >not just one users personal account on a single site. Also protect >against SQL injection attacks by sanitizing your data and so forth. Thank you for your thoughtful suggestions. I totally agree. If someone goes sniffing, or the like, they might be able to get somewhat limited access to the domain. On the other hand if they can crack the FTP, and get into the master server, they can download the whole site. >Finally, view it as your responsibility to never store anything personal >or identifying (or in fact anything) on the client side in a cookie - >one simple key (session_id) in the cookie and everything on the safe >secure server is the way to go. I have thought of storing customising information for a particular user in a cookie, but it would simply consist of a set of parameter values. As they would be processed in exactly the same way as if they had been entered as parameters they would presumably represent no more, or less, threat than the parameters which are essential to the operation of the site (and which can readily be read, or bookmarked -- or, on reflection, experimented with). -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
