Source of: /manual/en/security.globals.php
<?php
include_once $_SERVER['DOCUMENT_ROOT'] . '/include/shared-manual.inc';
$TOC = array();
$PARENTS = array();
include_once dirname(__FILE__) ."/toc/security.inc";
$setup = array (
'home' =>
array (
0 => 'index.php',
1 => 'PHP Manual',
),
'head' =>
array (
0 => 'UTF-8',
1 => 'en',
),
'this' =>
array (
0 => 'security.globals.php',
1 => 'Using Register Globals',
),
'up' =>
array (
0 => 'security.php',
1 => 'Security',
),
'prev' =>
array (
0 => 'security.errors.php',
1 => 'Error Reporting',
),
'next' =>
array (
0 => 'security.variables.php',
1 => 'User Submitted Data',
),
);
$setup["toc"] = $TOC;
$setup["parents"] = $PARENTS;
manual_setup($setup);
manual_header();
?>
<div>
<h1>Using Register Globals</h1>
<div class="warning"><b class="warning">Warning</b><p class="simpara">This feature has been
<em class="emphasis">DEPRECATED</em> as of PHP 5.3.0 and <em class="emphasis">REMOVED</em> as of PHP 6.0.0.
Relying on this feature is highly discouraged.</p></div>
<p class="para">
Perhaps the most controversial change in PHP is when the default value
for the PHP directive <a href="ini.core.php#ini.register-globals" class="link">
register_globals</a> went from ON to OFF in PHP
<a href="http://www.php.net/releases/4_2_0.php" class="link external">» 4.2.0</a>. Reliance on this
directive was quite common and many people didn't even know it existed
and assumed it's just how PHP works. This page will explain how one can
write insecure code with this directive but keep in mind that the
directive itself isn't insecure but rather it's the misuse of it.
</p>
<p class="para">
When on, register_globals will inject your scripts with all
sorts of variables, like request variables from HTML forms. This
coupled with the fact that PHP doesn't require variable initialization
means writing insecure code is that much easier. It was a difficult
decision, but the PHP community decided to disable this directive by
default. When on, people use variables yet really don't know for sure
where they come from and can only assume. Internal variables that are
defined in the script itself get mixed up with request data sent by
users and disabling register_globals changes this. Let's demonstrate
with an example misuse of register_globals:
</p>
<p class="para">
</p><div class="example">
<p><b>Example #1 Example misuse with register_globals = on</b></p>
<div class="example-contents programlisting">
<div class="phpcode"><code><span style="color: #000000">
<span style="color: #0000BB"><?php<br /></span><span style="color: #FF8000">// define $authorized = true only if user is authenticated<br /></span><span style="color: #007700">if (</span><span style="color: #0000BB">authenticated_user</span><span style="color: #007700">()) {<br /> </span><span style="color: #0000BB">$authorized </span><span style="color: #007700">= </span><span style="color: #0000BB">true</span><span style="color: #007700">;<br />}<br /><br /></span><span style="color: #FF8000">// Because we didn't first initialize $authorized as false, this might be<br />// defined through register_globals, like from GET auth.php?authorized=1<br />// So, anyone can be seen as authenticated!<br /></span><span style="color: #007700">if (</span><span style="color: #0000BB">$authorized</span><span style="color: #007700">) {<br /> include </span><span style="color: #DD0000">"/highly/sensitive/data.php"</span><span style="color: #007700">;<br />}<br /></span><span style="color: #0000BB">?></span>
</span>
</code></div>
</div>
</div><p>
</p>
<p class="para">
When register_globals = on, our logic above may be compromised. When
off, <var class="varname">$authorized</var> can't be set via request so it'll
be fine, although it really is generally a good programming practice to
initialize variables first. For example, in our example above we might
have first done <i>$authorized = false</i>. Doing this
first means our above code would work with register_globals on or off as
users by default would be unauthorized.
</p>
<p class="para">
Another example is that of <a href="ref.session.php" class="link">sessions</a>.
When register_globals = on, we could also use
<var class="varname">$username</var> in our example below but again you must
realize that <var class="varname">$username</var> could also come from other
means, such as GET (through the URL).
</p>
<p class="para">
</p><div class="example">
<p><b>Example #2 Example use of sessions with register_globals on or off</b></p>
<div class="example-contents programlisting">
<div class="phpcode"><code><span style="color: #000000">
<span style="color: #0000BB"><?php<br /></span><span style="color: #FF8000">// We wouldn't know where $username came from but do know $_SESSION is<br />// for session data<br /></span><span style="color: #007700">if (isset(</span><span style="color: #0000BB">$_SESSION</span><span style="color: #007700">[</span><span style="color: #DD0000">'username'</span><span style="color: #007700">])) {<br /><br /> echo </span><span style="color: #DD0000">"Hello <b></span><span style="color: #007700">{</span><span style="color: #0000BB">$_SESSION</span><span style="color: #007700">[</span><span style="color: #DD0000">'username'</span><span style="color: #007700">]}</span><span style="color: #DD0000"></b>"</span><span style="color: #007700">;<br /><br />} else {<br /><br /> echo </span><span style="color: #DD0000">"Hello <b>Guest</b><br />"</span><span style="color: #007700">;<br /> echo </span><span style="color: #DD0000">"Would you like to login?"</span><span style="color: #007700">;<br /><br />}<br /></span><span style="color: #0000BB">?></span>
</span>
</code></div>
</div>
</div><p>
</p>
<p class="para">
It's even possible to take preventative measures to warn when forging is
being attempted. If you know ahead of time exactly where a variable
should be coming from, you can check to see if the submitted data is
coming from an inappropriate kind of submission. While it doesn't
guarantee that data has not been forged, it does require an attacker to
guess the right kind of forging. If you don't care where the request
data comes from, you can use <var class="varname"><a href="reserved.variables.request.php" class="classname">$_REQUEST</a></var> as it contains
a mix of GET, POST and COOKIE data. See also the manual section on
using <a href="language.variables.external.php" class="link">variables from external
sources</a>.
</p>
<p class="para">
</p><div class="example">
<p><b>Example #3 Detecting simple variable poisoning</b></p>
<div class="example-contents programlisting">
<div class="phpcode"><code><span style="color: #000000">
<span style="color: #0000BB"><?php<br /></span><span style="color: #007700">if (isset(</span><span style="color: #0000BB">$_COOKIE</span><span style="color: #007700">[</span><span style="color: #DD0000">'MAGIC_COOKIE'</span><span style="color: #007700">])) {<br /><br /> </span><span style="color: #FF8000">// MAGIC_COOKIE comes from a cookie.<br /> // Be sure to validate the cookie data!<br /><br /></span><span style="color: #007700">} elseif (isset(</span><span style="color: #0000BB">$_GET</span><span style="color: #007700">[</span><span style="color: #DD0000">'MAGIC_COOKIE'</span><span style="color: #007700">]) || isset(</span><span style="color: #0000BB">$_POST</span><span style="color: #007700">[</span><span style="color: #DD0000">'MAGIC_COOKIE'</span><span style="color: #007700">])) {<br /><br /> </span><span style="color: #0000BB">mail</span><span style="color: #007700">(</span><span style="color: #DD0000">"admin@example.com"</span><span style="color: #007700">, </span><span style="color: #DD0000">"Possible breakin attempt"</span><span style="color: #007700">, </span><span style="color: #0000BB">$_SERVER</span><span style="color: #007700">[</span><span style="color: #DD0000">'REMOTE_ADDR'</span><span style="color: #007700">]);<br /> echo </span><span style="color: #DD0000">"Security violation, admin has been alerted."</span><span style="color: #007700">;<br /> exit;<br /><br />} else {<br /><br /> </span><span style="color: #FF8000">// MAGIC_COOKIE isn't set through this REQUEST<br /><br /></span><span style="color: #007700">}<br /></span><span style="color: #0000BB">?></span>
</span>
</code></div>
</div>
</div><p>
</p>
<p class="para">
Of course, simply turning off register_globals does not mean your code
is secure. For every piece of data that is submitted, it should also be
checked in other ways. Always validate your user data and initialize
your variables! To check for uninitialized variables you may turn up
<a href="function.error-reporting.php" class="function">error_reporting()</a> to show
<b><tt class="constant">E_NOTICE</tt></b> level errors.
</p>
<p class="para">
For information about emulating register_globals being On or Off, see this <a href="faq.misc.php#faq.misc.registerglobals" class="link">FAQ</a>.
</p>
<blockquote><p><b class="note">Note</b>: <b>Superglobals: availability note
</b><br />Superglobal arrays such as <var class="varname"><a href="reserved.variables.get.php" class="classname">$_GET</a></var>,
<var class="varname"><a href="reserved.variables.post.php" class="classname">$_POST</a></var>, and <var class="varname"><a href="reserved.variables.server.php" class="classname">$_SERVER</a></var>, etc. are available
as of PHP 4.1.0. For more information, read the manual section on
<a href="language.variables.predefined.php" class="link">superglobals</a><br /></p></blockquote>
</div>
<?php manual_footer(); ?>
