Ilia Alshanetsky wrote:
IMHO we should restrict or "disabling" code to just the
include/require constructs, since that is the main cause for concern.
Ultimately shy of disabling php's ability to request remote files
there is no way to prevent an attacker from fetching remote code and
then executing it. However, disabling all ability to query remote data
sources severely cripples PHP capabilities, making many applications
that need to do just that stop working.
Applications which require exactly these php capabilities (like soap or
even xslt on local files(!)) need to set allow_url_fopen to on because
otherwise they stop working. In that way application developers have to
decide to be "secure" and without functionality or "less secure" with
required capabilities. that makes this flag-as-is useless.
IMHO it is highly neccessary to be able to generally disable remote
include/require but also to be able to explizitely to enable it again
for certain parts of application code.
I know that this discussion was on more than once already, but the
current way allow_url_fopen works (e.g. because it is INI_SYSTEM only)
is just to restrictive forcing me and others to keep it enabled for
functionality reasons. I at least would be able to disable it in general
but enable it again on certain scripts within httpd.conf or .htaccess
files). Several proposals how to do that have been already written to
this list, I think.
mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
