Rasmus Lerdorf schrieb:
The best thing about PHP is that it has such a shallow learning curve that
non-programmers can write web apps.The worst thing about PHP is that it has such a shallow learning curve
that non-programmers write web apps.That is of course oversimplifying things quite a bit, but it is the root
of the issue here.The question is not whether we should do something about this, the
question is what we should do about it. After reading all these messages
and talking to people about it in person, here is what I see we need to
achieve (not necessarily in order of importance):1. A painless migration path for existing code
2. Minimal impact on the learning curve. I really don't like requiring
neophyte users to have to understand associative arrays before they
can get started with PHP.
3. Maximum protection for existing and new PHP appsHow to get there...
For 4.0.7:
- We leave all default configuration settings as they are now.
- We add $_GET, $_POST, $_COOKIE, $_ENV, $_SERVER and perhaps make them
super-globals like $GLOBALS
- We add a new function, somewhat like the current extract() which looks
something like this:// Import all Get/Post/Cookie variables in to the global(/current?)
// namespace. Function could also be called import_symbols() or
// register_globals() although the latter would be a bit confusing
// since it doesn't take a boolean arg like the ini version.
// If register_globals is on already this would be a no-op
import_globals("GPC");// Another use:
// Only import the given variables from Post or Cookie data.
import_globals("PC",array('user','password','first','last'));// And perhaps some globbing:
// Import any variable with abc in its name from anywhere.
// Could alternatively use SQL-style or perhaps real regex
// expressions here although I think full regex support would be
// slightly overkill and perhaps too confusing for people.
import_globals("GPCES","*abc*");
- With the release of 4.0.7 we start hyping this security issue by
linking to a spruced up version of the security chapter in the manual
which describes how exactly to use these new tools.
We could also provide a user-space implementation of the _$GET,
$_POST... population logic and a user-space implementation of
import_globals() so existing applications could check the PHP version
and include our forward-compliance.inc file in order for their apps
that conform to the new style to be backward compatible with older
PHP installations. Or better, our .inc/.php file would do a version
check for them.
- We also start hyping that people who write and distribute PHP apps
should strive to make their code E_NOTICE-clean.For 4.0.8:
- If we didn't mess up in 4.0.7 and actually got something that works for
people we consider turning on E_NOTICE by default and/or turning
register_globals off by default.For 4.1:
- I think a namespace approach might be interesting, although perhaps
hard to get as granular as import_globals()Reasoning behind something like import_globals():
Large existing web apps reference these GPECS variables everywhere. There
may literally be thousands of lines of code to change and perhaps 10's of
thousands of lines of code to check. Simply turning off register_globals
would make these scripts fail invisibly. The end result will be that
people just turn register_globals back on which may even be the documented
requirement for these distributed apps. This doesn't help anybody.However, if the authors of these apps could make their code somewhat more
secure by simply adding:import_globals("P");
to their app-wide include file and assuming they only want POST variables
imported, then they would probably do that. It isn't much of a security
benefit at this level, but if they took it slightly further and checked
their forms for form elements and pulled out the valid ones and specified
these in an array we suddenly have a whole lot more security and instead
of changing thousands of lines, they have added perhaps 5 or 6.And from a neophyte user perspective they don't need to understand
associative arrays, they simply need to understand
import_globals("GPC","form_*") which is much easier to teach. (assuming
they named their form elements form_foo, form_bar, ...)Obviously the import_globals documentation should point people at the
_GET[] direct access approach as well, although an import_globals() call
with a precise list of valid variables should be even safer.-Rasmus
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
