On Sun, 24 Jan 2010 17:44:16 +1100, clancy_1@xxxxxxxxxxxx wrote: >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). Well! My reflection above cast a completely different light on the situation. It turns out that from a security point of view the multiple domains of Quadra Hosting's scheme should all be regarded as a single domain. In this system each domain has a separate directory under the site root directory. I suspect that any browser access to any of the domains is treated as user group 'other' (with the site owner being owner). This means that any program operating in any domain can read any file in any of the other domains, or in any other directory in the site. This is a bad enough security hole, but in my system I have a separate directory 'Engine' containing the logic to display any of the pages in any of the domains. Each domain has a separate copy of index.php, which sets up a few variables, and then invokes the engine. The individual pages are displayed by a call to index.php, followed by a series of parameters. I have one 'secure' site which is password protected, and engine won't do anything until the user has logged in. However the parameter system can handle indirect paths, and I discovered this morning that if I opened a page on one of the other domains, and then passed the appropriate parameters, I could get into the secure domain, and navigate normally through it. Images are not displayed, as the path is not calculated correctly, but everything else is, and you can read the image properties, and from this work out their correct path. Even worse, if you know their addresses, you can download any of the images or data files simply by typing the address into a browser. I could prevent the cross coupling trick by blocking any path referring to the secure directory, and I could put the data files in a separate directory off to the side, so that they could not be directly downloaded, but as the browser has to be able to download the images (and any documents or spreadsheets) directly I cannot see any easy way to protect them. So much for worrying about the relative virtues of cookies and sessions! Clancy -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
