It’s been a long road and exactly five years (35 releases) since the much discussed and highly controversial PHP directive register_globals has been disabled by default in PHP. After sifting through the mailing list archives, the following set of information has been compiled. Feel free to make additions, corrections, and report register_globals memories!
First, a few tidbits
- As of today, April 22, 2007, register_globals has been disabled (by default) for five years. That’s when PHP 4.2.0 was released.
- PHP 3 did not have register_globals because it was simply how PHP behaved. However, some people used $HTTP_*_VARS if track_vars was on (it was on by default, and always on since PHP 4.0.3).
- You cannot set register_globals at runtime, and there have been at least 100 [deleted] user comments within the manual showing hacks how. This FAQ shows how. Don’t do it though.
- The order variables are registered via register_globals is determined by variables_order, a directive that also affects which variables (including superglobals) will exist in PHP. Don’t let the name fool you, this is one powerful PHP directive! In PHP 3, gpc_order was used instead.
- Most “Why PHP is insecure” articles show how to write insecure code with register_globals = on, and eventually register_globals (not poor programming) is blamed as the culprit. It rarely is.
- Strangely the 4.2.0 release announcement does not contain the string “register_globals” but of course it refers to it, and is highlighted in the ChangeLog.
- There’s plenty of code within cvsold.php.net that requires register_globals = on but that’s okay because it’s not a big concern. It however is slowly being updated.
A somewhat brief timeline
Continue reading A brief unofficial history about register_globals in PHP
