Sophie

Sophie

distrib > Mageia > 4 > i586 > by-pkgid > f800694edefe91adea2624f711a41a2d > files > 11266

php-manual-en-5.5.7-1.mga4.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
 <head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  <title>Using Register Globals</title>

 </head>
 <body><div class="manualnavbar" style="text-align: center;">
 <div class="prev" style="text-align: left; float: left;"><a href="security.errors.html">Error Reporting</a></div>
 <div class="next" style="text-align: right; float: right;"><a href="security.variables.html">User Submitted Data</a></div>
 <div class="up"><a href="security.html">Security</a></div>
 <div class="home"><a href="index.html">PHP Manual</a></div>
</div><hr /><div id="security.globals" class="chapter">
   <h1>Using Register Globals</h1>

   <div class="warning"><strong class="warning">Warning</strong><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 5.4.0.</p></div>
   <p class="para">
    Perhaps the most controversial change in <acronym title="PHP: Hypertext Preprocessor">PHP</acronym> is when the default value
    for the <acronym title="PHP: Hypertext Preprocessor">PHP</acronym> directive <a href="ini.core.html#ini.register-globals" class="link">
    register_globals</a> went from ON to OFF in <acronym title="PHP: Hypertext Preprocessor">PHP</acronym> 
    <a href="http://www.php.net/releases/4_2_0.php" class="link external">&raquo;&nbsp;4.2.0</a>.  Reliance on this
    directive was quite common and many people didn&#039;t even know it existed
    and assumed it&#039;s just how <acronym title="PHP: Hypertext Preprocessor">PHP</acronym> works.  This page will explain how one can
    write insecure code with this directive but keep in mind that the
    directive itself isn&#039;t insecure but rather it&#039;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 <acronym title="Hyper Text Markup Language">HTML</acronym> forms.  This
    coupled with the fact that <acronym title="PHP: Hypertext Preprocessor">PHP</acronym> doesn&#039;t require variable initialization
    means writing insecure code is that much easier.  It was a difficult
    decision, but the <acronym title="PHP: Hypertext Preprocessor">PHP</acronym> community decided to disable this directive by 
    default.  When on, people use variables yet really don&#039;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&#039;s demonstrate
    with an example misuse of register_globals: 
   </p>
   <p class="para">
    <div class="example" id="example-342">
     <p><strong>Example #1 Example misuse with register_globals = on</strong></p>
     <div class="example-contents">
<div class="phpcode"><code><span style="color: #000000">
<span style="color: #0000BB">&lt;?php<br /></span><span style="color: #FF8000">//&nbsp;define&nbsp;$authorized&nbsp;=&nbsp;true&nbsp;only&nbsp;if&nbsp;user&nbsp;is&nbsp;authenticated<br /></span><span style="color: #007700">if&nbsp;(</span><span style="color: #0000BB">authenticated_user</span><span style="color: #007700">())&nbsp;{<br />&nbsp;&nbsp;&nbsp;&nbsp;</span><span style="color: #0000BB">$authorized&nbsp;</span><span style="color: #007700">=&nbsp;</span><span style="color: #0000BB">true</span><span style="color: #007700">;<br />}<br /><br /></span><span style="color: #FF8000">//&nbsp;Because&nbsp;we&nbsp;didn't&nbsp;first&nbsp;initialize&nbsp;$authorized&nbsp;as&nbsp;false,&nbsp;this&nbsp;might&nbsp;be<br />//&nbsp;defined&nbsp;through&nbsp;register_globals,&nbsp;like&nbsp;from&nbsp;GET&nbsp;auth.php?authorized=1<br />//&nbsp;So,&nbsp;anyone&nbsp;can&nbsp;be&nbsp;seen&nbsp;as&nbsp;authenticated!<br /></span><span style="color: #007700">if&nbsp;(</span><span style="color: #0000BB">$authorized</span><span style="color: #007700">)&nbsp;{<br />&nbsp;&nbsp;&nbsp;&nbsp;include&nbsp;</span><span style="color: #DD0000">"/highly/sensitive/data.php"</span><span style="color: #007700">;<br />}<br /></span><span style="color: #0000BB">?&gt;</span>
</span>
</code></div>
     </div>

    </div>
   </p>
   <p class="para">
    When register_globals = on, our logic above may be compromised.  When
    off, <var class="varname"><var class="varname">$authorized</var></var> can&#039;t be set via request so it&#039;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 <em>$authorized = false</em>.  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.html" class="link">sessions</a>.
    When register_globals = on, we could also use
    <var class="varname"><var class="varname">$username</var></var> in our example below but again you must
    realize that <var class="varname"><var class="varname">$username</var></var> could also come from other
    means, such as GET (through the <acronym title="Uniform Resource Locator">URL</acronym>).
   </p>
   <p class="para">
    <div class="example" id="example-343">
     <p><strong>Example #2 Example use of sessions with register_globals on or off</strong></p>
     <div class="example-contents">
<div class="phpcode"><code><span style="color: #000000">
<span style="color: #0000BB">&lt;?php<br /></span><span style="color: #FF8000">//&nbsp;We&nbsp;wouldn't&nbsp;know&nbsp;where&nbsp;$username&nbsp;came&nbsp;from&nbsp;but&nbsp;do&nbsp;know&nbsp;$_SESSION&nbsp;is<br />//&nbsp;for&nbsp;session&nbsp;data<br /></span><span style="color: #007700">if&nbsp;(isset(</span><span style="color: #0000BB">$_SESSION</span><span style="color: #007700">[</span><span style="color: #DD0000">'username'</span><span style="color: #007700">]))&nbsp;{<br /><br />&nbsp;&nbsp;&nbsp;&nbsp;echo&nbsp;</span><span style="color: #DD0000">"Hello&nbsp;&lt;b&gt;</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">&lt;/b&gt;"</span><span style="color: #007700">;<br /><br />}&nbsp;else&nbsp;{<br /><br />&nbsp;&nbsp;&nbsp;&nbsp;echo&nbsp;</span><span style="color: #DD0000">"Hello&nbsp;&lt;b&gt;Guest&lt;/b&gt;&lt;br&nbsp;/&gt;"</span><span style="color: #007700">;<br />&nbsp;&nbsp;&nbsp;&nbsp;echo&nbsp;</span><span style="color: #DD0000">"Would&nbsp;you&nbsp;like&nbsp;to&nbsp;login?"</span><span style="color: #007700">;<br /><br />}<br /></span><span style="color: #0000BB">?&gt;</span>
</span>
</code></div>
     </div>

    </div>
   </p>
   <p class="para">
    It&#039;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&#039;t
    guarantee that data has not been forged, it does require an attacker to
    guess the right kind of forging.  If you don&#039;t care where the request
    data comes from, you can use <var class="varname"><var class="varname"><a href="reserved.variables.request.html" class="classname">$_REQUEST</a></var></var> as it contains
    a mix of GET, POST and COOKIE data.  See also the manual section on
    using <a href="language.variables.external.html" class="link">variables from external
    sources</a>.
   </p>
   <p class="para">
    <div class="example" id="example-344">
     <p><strong>Example #3 Detecting simple variable poisoning</strong></p>
     <div class="example-contents">
<div class="phpcode"><code><span style="color: #000000">
<span style="color: #0000BB">&lt;?php<br /></span><span style="color: #007700">if&nbsp;(isset(</span><span style="color: #0000BB">$_COOKIE</span><span style="color: #007700">[</span><span style="color: #DD0000">'MAGIC_COOKIE'</span><span style="color: #007700">]))&nbsp;{<br /><br />&nbsp;&nbsp;&nbsp;&nbsp;</span><span style="color: #FF8000">//&nbsp;MAGIC_COOKIE&nbsp;comes&nbsp;from&nbsp;a&nbsp;cookie.<br />&nbsp;&nbsp;&nbsp;&nbsp;//&nbsp;Be&nbsp;sure&nbsp;to&nbsp;validate&nbsp;the&nbsp;cookie&nbsp;data!<br /><br /></span><span style="color: #007700">}&nbsp;elseif&nbsp;(isset(</span><span style="color: #0000BB">$_GET</span><span style="color: #007700">[</span><span style="color: #DD0000">'MAGIC_COOKIE'</span><span style="color: #007700">])&nbsp;||&nbsp;isset(</span><span style="color: #0000BB">$_POST</span><span style="color: #007700">[</span><span style="color: #DD0000">'MAGIC_COOKIE'</span><span style="color: #007700">]))&nbsp;{<br /><br />&nbsp;&nbsp;&nbsp;</span><span style="color: #0000BB">mail</span><span style="color: #007700">(</span><span style="color: #DD0000">"admin@example.com"</span><span style="color: #007700">,&nbsp;</span><span style="color: #DD0000">"Possible&nbsp;breakin&nbsp;attempt"</span><span style="color: #007700">,&nbsp;</span><span style="color: #0000BB">$_SERVER</span><span style="color: #007700">[</span><span style="color: #DD0000">'REMOTE_ADDR'</span><span style="color: #007700">]);<br />&nbsp;&nbsp;&nbsp;echo&nbsp;</span><span style="color: #DD0000">"Security&nbsp;violation,&nbsp;admin&nbsp;has&nbsp;been&nbsp;alerted."</span><span style="color: #007700">;<br />&nbsp;&nbsp;&nbsp;exit;<br /><br />}&nbsp;else&nbsp;{<br /><br />&nbsp;&nbsp;&nbsp;</span><span style="color: #FF8000">//&nbsp;MAGIC_COOKIE&nbsp;isn't&nbsp;set&nbsp;through&nbsp;this&nbsp;REQUEST<br /><br /></span><span style="color: #007700">}<br /></span><span style="color: #0000BB">?&gt;</span>
</span>
</code></div>
     </div>

    </div>
   </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
     <span class="function"><a href="function.error-reporting.html" class="function">error_reporting()</a></span> to show
    <strong><code>E_NOTICE</code></strong> level errors.
   </p>
   <p class="para">
    For information about emulating register_globals being On or Off, see this <a href="faq.misc.html#faq.misc.registerglobals" class="link">FAQ</a>.
   </p>

   <blockquote class="note"><p><strong class="note">Note</strong>: <strong>Superglobals: availability note
</strong><br /><p class="para">Superglobal arrays such as <var class="varname"><var class="varname"><a href="reserved.variables.get.html" class="classname">$_GET</a></var></var>,
<var class="varname"><var class="varname"><a href="reserved.variables.post.html" class="classname">$_POST</a></var></var>, and <var class="varname"><var class="varname"><a href="reserved.variables.server.html" class="classname">$_SERVER</a></var></var>, etc. are available
as of PHP 4.1.0. For more information, read the manual section on
<a href="language.variables.predefined.html" class="link">superglobals</a></p></p></blockquote>

  </div>
<hr /><div class="manualnavbar" style="text-align: center;">
 <div class="prev" style="text-align: left; float: left;"><a href="security.errors.html">Error Reporting</a></div>
 <div class="next" style="text-align: right; float: right;"><a href="security.variables.html">User Submitted Data</a></div>
 <div class="up"><a href="security.html">Security</a></div>
 <div class="home"><a href="index.html">PHP Manual</a></div>
</div></body></html>