Proposal

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 apps How 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