PHP
downloads | documentation | faq | getting help | mailing lists | reporting bugs | php.net sites | links | conferences | my php.net

search for in the

ユーザが投稿したデータ> <エラーのレポート
Last updated: Fri, 10 Oct 2008

view this page in

グローバル変数の登録機能の使用法

警告

この機能は 非推奨 であり、PHP 6.0.0 で 削除 されます。この機能を使用しないことを強く推奨します。

PHPの変更点で最も議論の対象となったのは、おそらく、PHP » 4.2.0において PHPのディレクティブ register_globalsが デフォルトでONからOFFに変更された時でしょう。 当時、このディレクティブに依存することが一般的であり、多くの人は、 このパラメータの存在すら知らず、PHPの動作そのものであるというよう に考えていました。このページは、このディレクティブにより安全でな いコードを書く可能性があるということをこのページで説明しますが、 このディレクティブそのものが安全でないわけではなく、これを誤って使 用することが安全でないということを念頭においていてください。

register_globalsをonとした場合、この機能により、HTMLフォームから投 稿される変数と同時に、あらゆる種類の変数がスクリプトに注入される ことになります。これは、PHPにおいては変数の初期化が不 要であるということにも関係し、安全でないコードを書くことが極めて容 易になるということを意味します。困難な変更でしたが、PHPコミュニティ は、このディレクティブをデフォルトで無効とすることを決定しました。 onとした場合、どこから来たのかが不明であり、出処を仮定するしかない 変数を使用することになります。スクリプト自体で定義される内部変数は、 ユーザにより送信されたリクエストデータと混ざってしまいますが、 register_globals を無効とすることでこれを回避することができます。 以下にregister_globalsの誤った使用例を示しましょう。

例1 register_globals = on の誤った使用例

<?php
// ユーザが認証された場合のみ $authorized = true を定義する
if (authenticated_user()) {
    
$authorized true;
}

// 最初に$authorizedをfalseとして初期化していないため、
// 以下のコードにより、GET auth.php?authorized=1 のように
// register_globals機能により定義される可能性があります。
// このため、誰でも認証されたようにみせることができます!
if ($authorized) {
    include 
"/highly/sensitive/data.php";
}
?>

register_globals = onとした場合、上記のロジックは破綻する可能性が あります。offの場合、$authorizedはリクエストに より設定することはできず、正しく動作します。しかし、一般に良いプロ グラミング法は、変数を最初に初期化することです。例えば、上の例で $authorized = falseを先頭に置いておくことができ ます。これにより、ユーザはデフォルトで認証されない状態となるため、 register_globalsのon/offによらず上記のコードは動作します。

別の例は、 セッションに関するも のです。register_globals = onとした場合、以下の例で $usernameを使用することもできますが、 (URLにより)GETのような他の手段によっても $username を設定することができることに留意する 必要があります。

例2 register_globals on またはoffの場合のセッションの使用例

<?php
// $usernameの出処は不明だが、$_SESSIONがセッションデータであることは
// 既知です。
if (isset($_SESSION['username'])) {

    echo 
"Hello <b>{$_SESSION['username']}</b>";

} else {

    echo 
"Hello <b>Guest</b><br />";
    echo 
"Would you like to login?";

}
?>

偽造が試みられた時に警告するために予防的な計測を行うことも可能です。 ある変数の出処を前もって正確に知っている場合、 投稿されたデータが適切な投稿元からのものであるかを調べることができ ます。これは、データが偽造されたものでないことを保証するわけではあ りませんが、攻撃者による偽造の成立を限定的なものにすることができま す。リクエストデータの出処を気にかけない場合、 $_REQUEST を使用することができます。 この変数には、GET、POST、COOKIEが合わさって含まれています。 本マニュアルの 外部から来る変数 のセクションを参照してください。

例3 簡単に変数汚染を検出する

<?php
if (isset($_COOKIE['MAGIC_COOKIE'])) {

    
// MAGIC_COOKIE comes from a cookie.
    // Be sure to validate the cookie data!

} elseif (isset($_GET['MAGIC_COOKIE']) || isset($_POST['MAGIC_COOKIE'])) {

   
mail("admin@example.com""Possible breakin attempt"$_SERVER['REMOTE_ADDR']);
   echo 
"Security violation, admin has been alerted.";
   exit;

} else {

   
// MAGIC_COOKIE isn't set through this REQUEST

}
?>

もちろん、register_globalsをoffにするだけでは、使用するコードが安 全であることを意味しません。投稿された全てのデータ毎に 他の手段で検証することも必要です。ユーザデータを常に検証し、 使用する変数を初期化してください! 初期化されていない変数を調べるには、 error_reporting()E_NOTICEレベルのエラーを有効にするように してください。

register_globalsをOnまたはOffのエミュレートに関数情報に ついては、FAQを 参照してください。

注意: スーパーグローバル: 使用可能なバージョンに関する注意
PHP 4.1.0 以降、 $_GET, $_POST, $_SERVER 等のスーパーグローバル配列が使用可能となっています。 詳細な情報については、マニュアルの superglobals のセクションを参照してください。



add a note add a note User Contributed Notes
グローバル変数の登録機能の使用法
bohwaz
31-Aug-2008 10:39
<?php

// Unregister_globals: unsets all global variables set from a superglobal array
// --------------------
// This is useful if you don't know the configuration of PHP on the server the application
// will be run
// Place this in the first lines of all of your scripts
// Don't forget that the register_global of $_SESSION is done after session_start() so after
// each session_start() put a unregister_globals('_SESSION');

function unregister_globals()
{
    if (!
ini_get('register_globals'))
    {
        return
false;
    }

    foreach (
func_get_args() as $name)
    {
        foreach (
$GLOBALS[$name] as $key=>$value)
        {
            if (isset(
$GLOBALS[$key]))
                unset(
$GLOBALS[$key]);
        }
    }
}

unregister_globals('_POST', '_GET', '_COOKIE', '_REQUEST', '_SERVER', '_ENV', '_FILES');

?>
moore at hs-furtwangen dot de
14-Jul-2008 09:19
I had a look at the post from Dice, in which he suggested the function unregister_globals(). It didn't seem to work - only tested php 4.4.8 and 5.2.1 - so I made some tweaking to get it running. (I had to use $GLOBALS due to the fact that $$name won't work with superglobals).

<?php
//Undo register_globals
function unregister_globals() {
    if (
ini_get('register_globals')) {
       
$array = array('_REQUEST', '_FILES');
        foreach (
$array as $value) {
            if(isset(
$GLOBALS[$value])){
                foreach (
$GLOBALS[$value] as $key => $var) {
                    if (isset(
$GLOBALS[$key]) && $var === $GLOBALS[$key]) {
                       
//echo 'found '.$key.' = '.$var.' in $'.$value."\n";                   
                       
unset($GLOBALS[$key]);
                    }
                }
            }
        }
    }
}
?>

The echo was for debuging, thought it might come in handy.
stranger at teuton dot org
10-Jul-2008 12:48
RE: Anonymous on oirinely at yahoo dot com

Actually oirinely is correct. With register_globals on any key in $_SESSION becomes a global variable when session_start() happens. This means that assigning a value to any variable that has the same name as any existing $_SESSION key (when register_globals is on and session_start() has happened) is the same as assigning to $_SESSION

e.g.
<?php
session_start
();
$_SESSION['foo'] = 1;
$foo = 2;
echo
$_SESSION['foo'];
?>

result = 1
Anonymous
29-Apr-2008 12:14
oirinely at yahoo dot com -
that piece of code will not print another value unless it looks like this:

<?php
$_SESSION
['value'] = 'some value';

$value = 'another value';

$_SESSION['value'] = $value; // with this line in, $_SESSION['value'] now equals $value so it will be insecure

echo $_SESSION['value'];

?>
fab dot mariotti at [google]gmail dot com
16-Apr-2008 08:59
For my application I defined two functions:
wit_set_gv('space','key','value')
wit_get_gv('space','key')
Forgive the "wit_" prefix but the gv stays for Global Variable.

Maybe I should start with a simple version:
wit_set_gv('key','value')
wit_get_gv('key')

This way you would set or get a global/session value.
The register_globals (on or off), session state and/or
superglobal variables will be handled by these functions.

I did add a 'space' item because I wanted to have control
on what goes to/comes from where. As an example if I call:
wit_get_gv('WIT_CONF','URL')
I know that I have to check for a global variable named
WIT_CONF which also gives me a positive responce
on isset($WIT_CONF['URL']). In this case $WIT_CONF
is global and static. But I can also set up a $WIT_STATE
variable which will represent the state of the transaction.
Using the code of WIT_set_gv() and WIT_get_gv(), with the help
of a simple few lines (in my case: include globals.inc.php)
definition script I handle this problem.

In my case, for example, if 'WIT_STATE' (or other names)
is not a defined globally available variable I default to check
for a session variable.

For example you might warn or stop if a requested named variable
matches a $_POST, $_GET or $_SESSION variable name while you
do not expect so. i.e. all my private data has a wit_ prefix
but no public request has (shouldn't have) this prefix.

Oopss. I do realize that this comment might not be in the proper
place. i.e. "register_globals". Indeed it might give some advice
to users still using register_globals and willing to change the
code for a "better" solution. Of course                                                                                the simple switching to "register_globals = off" might not solve
the securities issues.

Cheers
F
Dice
16-Apr-2008 05:46
To expand on the nice bit of code Mike Willbanks wrote and Alexander tidied up, I turned the whole thing in a function that removes all the globals added by register_globals so it can be implemented in an included functions.php and doesn't litter the main pages too much.

<?php
//Undo register_globals
function unregister_globals() {
    if (
ini_get(register_globals)) {
       
$array = array('_REQUEST', '_SESSION', '_SERVER', '_ENV', '_FILES');
        foreach (
$array as $value) {
            foreach (
$GLOBALS[$value] as $key => $var) {
                if (
$var === $GLOBALS[$key]) {
                    unset(
$GLOBALS[$key]);
                }
            }
        }
    }
}
?>
Ruquay K Calloway
01-Apr-2008 02:59
While we all appreciate the many helpful posts to get rid of register_globals, maybe you're one of those who just loves it.  More likely, your boss says you just have to live with it because he thinks it's a great feature.

No problem, just call (below defined):

<?php register_globals(); ?>

anywhere, as often as you want.  Or update your scripts!

<?php
/**
 * function to emulate the register_globals setting in PHP
 * for all of those diehard fans of possibly harmful PHP settings :-)
 * @author Ruquay K Calloway
 * @param string $order order in which to register the globals, e.g. 'egpcs' for default
 */
function register_globals($order = 'egpcs')
{
   
// define a subroutine
   
if(!function_exists('register_global_array'))
    {
        function
register_global_array(array $superglobal)
        {
            foreach(
$superglobal as $varname => $value)
            {
                global $
$varname;
                $
$varname = $value;
            }
        }
    }
   
   
$order = explode("\r\n", trim(chunk_split($order, 1)));
    foreach(
$order as $k)
    {
        switch(
strtolower($k))
        {
            case
'e':    register_global_array($_ENV);        break;
            case
'g':    register_global_array($_GET);        break;
            case
'p':    register_global_array($_POST);        break;
            case
'c':    register_global_array($_COOKIE);    break;
            case
's':    register_global_array($_SERVER);    break;
        }
    }
}
?>
subarea
20-Mar-2008 04:43
If you have no access to php.ini and the solution with
the .htaccess entry (php_flag register_globals 0)
also doesn't work or you are just a little bit paranoid,
you can use the following script.

this is just a workaround to kill all (through register globals) imported vars!

<?php
foreach(array_keys($_REQUEST) as $var_to_kill) unset($$var_to_kill);
foreach(
array_keys($_SESSION) as $var_to_kill) unset($$var_to_kill);
foreach(
array_keys($_SERVER) as $var_to_kill)  unset($$var_to_kill);
                                               unset(
$var_to_kill);
?>

if you like it, just drop me a line...

greetz subarea
dot dot dot dot dot alexander at gmail dot com
09-Mar-2008 02:19
@ Mike Willbanks's post
This is an even cleaner version of your code:

<?php
if( ini_get(register_globals) ) {
/* genocide the damn registered globals if they are on */
   
foreach( $_REQUEST as $key => $var ){
        if(
$var === $$key ){
            unset($
$key);
        }
    }
}
?>
oirinel at yahoo dot com
18-Dec-2007 08:35
when using register_globals=On be careful since using something like:

$_SESSION['value'] = 'some value';

$value = 'another value';

echo $_SESSION['value']; // !!! will print 'another value' !!!!

Hope this will save someone from headaches and from loosing hours!
Tumasch
13-Dec-2007 01:50
In addition to Mike Willbanks post:

Put this to the beginning of every file or to a functions.inc.php and call it every time before start working with user variables.
This will prevent problems with wrong initalized variables or users who try to break your application.

And this has an extra bonus: Applications which still work are also register_globasl = off enabled!

<?php
//
// If register_globals is on, delete all variables exept the ones in the array
//
if (ini_get('register_globals')) {
    foreach (
$GLOBALS as $int_temp_name => $int_temp_value) {
        if (!
in_array($int_temp_name, array (
               
'GLOBALS',
               
'_FILES',
               
'_REQUEST',
               
'_COOKIE',
               
'_SERVER',
               
'_ENV',
               
'_SESSION',
               
ini_get('session.name'),
               
'int_temp_name',
               
'int_temp_value'
           
))) {
            unset (
$GLOBALS[$int_temp_name]);
        }
    }
}
//
// Now, (re)import the variables
//
if (isset ($_REQUEST['pass']))
   
$ext_pass = $_REQUEST['pass'];
if (isset (
$_REQUEST['user']))
   
$ext_user = $_REQUEST['user'];
if (isset (
$_REQUEST['action']))
   
$ext_action = $_REQUEST['action'];
//
// Cleanup entries
//
$int_pass = (isset ($ext_pass) ? preg_replace("'[^A-Z]'", "", $ext_pass) : '');
$int_user = (isset ($ext_user) ? preg_replace("'[]A-Za-z0-9áäàâãëèéêïìîóöòôõúüùû \.^\$\!\_-()'", "", $ext_user) : '');
$int_action = (isset ($ext_action) ? intval($ext_action) : '');
//
// Import Session variables
//
if (isset ($_SESSION)) {
    foreach (
$_SESSION as $int_temp_key => $int_temp_value) {
        if (
$int_temp_value != '') {
            $
$int_temp_key = $int_temp_value;
        }
    }
}
//
// Import Cookie variables
//
if (isset ($_COOKIE)) {
    foreach (
$_COOKIE as $int_temp_key => $int_temp_value) {
        if (
$int_temp_value != '') {
            $
$int_temp_key = $int_temp_value;
        }
    }
}
//
// From here on, work only with $int_ variables and you're safe!
//
?>

With this you can prevent a lot of different problems!
Mike Willbanks
05-Sep-2007 04:40
Sorry the last php code I submitted was formatted nice but I changed some things for readability and didn't implement it across the board.  Here is the correct code:

<?php
if (ini_get(register_globals)) {
   
$rg = array_keys($_REQUEST);
    foreach(
$rg as $var)
    {
        if (
$_REQUEST[$var] === $$var)
        {
            unset($
$var);
        }
    }
}
?>
Mike Willbanks
29-Aug-2007 07:15
Alans code may get rid of globals but it is slow since it is doing regular expressions on each of the input items.  Then to add on more time the code is being passed through eval.

Besides the slower performance, his code is not checking to see if the variable may have been changed at any state before this code is being done.

There might be auto_prepended files or include files that might need to run before it.  He is also going through get and post and lastly request which is a little silly seeing as request will contain the get, post and cookie so he has run get and post twice.

Here is a more effective fix that will take all the keys in request which become variable names and checks to make sure that the variables match then unsets the element.

<?php
if (ini_get(register_globals)) {
   
$rg = array_keys($_REQUEST);
    foreach(
$rg as $var)
    {
        if (
$_REQUEST[$v] === $$v)
        {
            unset($
$v);
        }
    }
}
?>
alan hogan
20-Jul-2007 04:08
Useful for shared hosting or scripts that you are sharing with other people.
<?php
// Effectively turn off dangerous register_globals without having to edit php.ini
if (ini_get(register_globals))  // If register_globals is enabled
{ // Unset $_GET keys
 
foreach ($_GET as $get_key => $get_value) {
    if (
ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $get_key)) eval("unset(\${$get_key});");
  }
// Unset $_POST keys
 
foreach ($_POST as $post_key => $post_value) {
    if (
ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $post_key)) eval("unset(\${$post_key});");

  }
// Unset $_REQUEST keys
 
foreach ($_REQUEST as $request_key => $request_value) {
    if (
ereg('^([a-zA-Z]|_){1}([a-zA-Z0-9]|_)*$', $request_key)) eval("unset(\${$request_key});");
  }
}
?>
Timbo
14-Jul-2007 04:25
In response to the above post by Caliwebman at yahoo dot com, a.k.a. "Gentle Warrior" who complained about the lack of documentation on register_globals:

I think this code snippet will address the *main* source of his confusion:

<?

function readyToBeAProgrammer()
{
 
$stuff=$_URINALYSIS['test'];

  if(
$stuff == THC)
  {
    return
false;
  }
  else
  {
    return
true;
  }

 
// register_globals is all about knowing where your variables are really coming from
  // what if a malicious user tried to pass off
  // $stuff=$_GET['someone_elses_drop']; // as $stuff ?
  // preventing this kind of substitution is the whole point
  // of disabling register_globals

}

if(!
readyToBeAProgrammer())
{
  die(
"Switch to coffee, man!");
}

?>

P.S., let's give it up in appreciation for the moderators who must sit though and clean up these boards, facetious posts like mine included...
caliwebman at yahoo dot com
10-Jul-2007 11:29
U know what I find incredibly insane? The fact that no where on the first pages <<<PLURAL does anyone even suggest where to find this code. And IF it exists in a file called "register_globals-etc..." than I have no clue why none of my sites have this file. It amazes me that we here on this side have made things so incredibly difficult on ourselves and the newer coders. Why? I thought that was what Microsoft was doing but quite honestly follks, we here on this side have MS beat when it comes to making things MUCH more of a challenge than they need be.

PLEASE, please dumb things down. And if you can't? ASK someone who is NOT in your bubble of code to review what you are writing in your dirstructions.... directions.... ask someoen like your MOM or DAD who know nothing of the code.

We sure would get going mch more quickly if we all paid attenttion to this simple rule.... and lastly, the front end designers are finally getting it together..... thank you, but again, remember, THE 3 CLICK RULE!!!

Peace,

Gentle Warrior
Scott
29-Jun-2007 06:19
I couldn't get any of the suggested ways to disable register_globals to work in what I believe to be an Apache environment, where even phpinfo() is disabled. I finally had to resort to

foreach(array_keys($_REQUEST) as $field)
{
    unset(${$field});
}

to get the $_REQUEST array without auto-setting all the request variables. I'm somewhat new to the whole PHP thing and wonder if there is a downside to this that I don't see.
someone at example dot com
17-Apr-2007 08:14
In reply to yyalcinkaya at ku edu tr you could just do this with $_REQUEST:

foreach($_REQUEST as $k => $v)
{
  ${$k} = $v;
}

...though doing something like this is asking for a world of trouble IMHO.
yyalcinkaya at ku edu tr
28-Mar-2007 11:37
if you want to keep register_globals off you can use this codes instead.

foreach($_POST AS $key => $value) {
    ${$key} = $value;
}

foreach($_GET AS $key => $value) {
    ${$key} = $value;
}
alan at xensource dot com
15-Nov-2005 05:00
From the PHP Manual page on Using register_globals:

Do not use extract() on untrusted data, like user-input ($_GET, ...). If you do, for example, if you want to run old code that relies on register_globals  temporarily, make sure you use one of the non-overwriting extract_type values such as EXTR_SKIP and be aware that you should extract in the same order that's defined in variables_order within the php.ini.
Dexter at dexpark dot com
06-Nov-2005 02:59
For Apache users or webhosters, you can set the
php_flag register_globals on/off in a VirtualHost context.
dyer85 at gmail dot com
05-Nov-2005 06:10
I'd suggest taking a look at php.net's source code for these user notes, if you want to get ideas on some nice ways to collect and validate user data.

http://php.net/source.php?url=/manual/add-note.php
hbinduni at gmail dot com
30-Oct-2005 09:06
[quote]
If you're under an Apache environment that has this option enabled, but you're on shared hosting so have no access to php.ini, you can unset this value for your own site by placing the following in an .htaccess file in the root:

php_flag register_globals 0
[/quote]

adding php_flag in .htaccess under apache 2 will cause internal server error. according to apache 2 manual, php_flag should goes to <virtual> or <directory> section.
ramosa (0) gmail dotty com
24-Sep-2005 05:24
Here's a one liner that works both with register globals on or off, and is even secure enough when it's on, as you make sure you init the var.

Using the ?: operator

$variable = isset($_GET["variable"]) ? $_GET["variable"] : "";
kcinick at ciudad dot com dot ar
18-May-2005 11:12
if you plan to use php_admin_value register_globals [0-1] inside <VirtualHost> in apache, forget it, it don't show any error messages in the configuration, but at the time of running, it enable and disables register_globals at random request, if you need to customize this param to multiple virtual host, put it in a <Directory> directives, it works fine there...

PD: same for safe_mode, etc...
ryanwray at gmail dot com
24-Nov-2004 03:03
In reply to ben at nullcreations dot net:

This is true of the super-global $_SESSION, as it will always be processed last (it is not considered in variables_order directive)

However, it is possible to over-write other data, namely GET, POST, COOKIE, ENVIROMENT and SERVER.

Of course, what you can overwrite will depend on the directive variables_order - by default, you could overwrite GET and POST data via COOKIE (because cookie data is processed last out of the three which should not really be of great concern.

My below code is irrelevant unless extract or another method which does the same thing (ie. I have seen variable variables used before to reach the same affect) is used.
ben at nullcreations dot net
23-Nov-2004 12:53
Just a note to all the people who think $_SESSION can be poisoned by register_globals - it can't.

Consider the fact that GET/POST/COOKIE is Processed *before* sessions are.  This means that even if you have register_globals on, and they write to $_SESSION, $_SESSION will just get reset again with the appropriate values.

Some people take to using extract() as a means to simulate register_globals in scripts where they're not sure what the server environment will be - this is when you should worry about such things.  The reason is because extract() can concievably occur after GET/POST/COOKIE and SESSION processing.
snarkles <anything at $myname dot net>
19-May-2004 08:06
If you're under an Apache environment that has this option enabled, but you're on shared hosting so have no access to php.ini, you can unset this value for your own site by placing the following in an .htaccess file in the root:

php_flag register_globals 0

The ini_set() function actually accomplishes nothing here, since the variables will have already been created by the time the script processes the ini file change.

And since this is the security chapter, just as a side note, another thing that's helpful to put into your .htaccess is:

<Files ".ht*">
deny from all
</Files>

That way no one can load .htaccess in their browser and have a peek at its contents.

Sorry, not aware of a similar workaround for IIS. :\
dav at thedevelopersalliance dot com
18-Dec-2003 06:38
import_request_variables() has a good solution to part of this problem - add a prefix to all imported variables, thus almost eliminating the factor of overriding internal variables through requests. you should still check data, but adding a prefix to imports is a start.

 
show source | credits | stats | sitemap | contact | advertising | mirror sites