本特性已自 PHP 5.3.0 起廢棄并將自 PHP 5.4.0 起移除。

可能 PHP 中最具爭議的變化就是從 PHP 4.2.0 版開始配置文件中 PHP 指令 register_globals 的默認值從 on 改為 off 了。對此選項的依賴是如此普遍以至于很多人根本不知道它的存在而以為 PHP 本來就是這么工作的。本節會解釋用這個指令如何寫出不安全的代碼，但要知道這個指令本身沒有不安全的地方，誤用才會。

當 register_globals 打開以后，各種變量都被注入代碼，例如來自 HTML 表單的請求變量。再加上 PHP 在使用變量之前是無需進行初始化的，這就使得更容易寫出不安全的代碼。這是個很艱難的抉擇，但 PHP 社區還是決定默認關閉此選項。當打開時，人們使用變量時確實不知道變量是哪里來的，只能想當然。但是 register_globals 的關閉改變了這種代碼內部變量和客戶端發送的變量混雜在一起的糟糕情況。下面舉一個錯誤使用 register_globals 的例子：

Example #1 錯誤使用 register_globals = on 的例子

<?php // 當用戶合法的時候，賦值 $authorized = true if (authenticated_user()) {$authorized = true; } // 由于并沒有事先把 $authorized 初始化為 false， // 當 register_globals 打開時，可能通過GET auth.php?authorized=1 來定義該變量值 // 所以任何人都可以繞過身份驗證 if ($authorized) {include '/highly/sensitive/data.php'; }?>

當 register_globals = on 的時候，上面的代碼就會有危險了。如果是 off，$authorized 就不能通過如 URL 請求等方式來改變，這樣就好多了，盡管初始化變量是一個良好的編程習慣。比如說，如果在上面的代碼執行之前加入 $authorized = false 的話，無論 register_globals 是 on 還是 off 都可以，因為用戶狀態被初始化為未經認證。

另一個例子是關于會話的。當 register_globals = on 的時候，$username 也可以用在下面的代碼中，但要意識到 $username 也可能會從其它途徑進來，比如說通過 URL 的 GET。

Example #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 的所有數據。

Example #3 探測有害變量

<?php if (isset($_COOKIE[’MAGIC_COOKIE’])) {// MAGIC_COOKIE 來自 cookie// 這樣做是確保是來自 cookie 的數據 } 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 變量 }?>

當然，單純地關閉 register_globals 并不代表所有的代碼都安全了。對于每一段提交上來的數據，都要對其進行具體的檢查。永遠要驗證用戶數據和對變量進行初始化！把error_reporting() 設為 E_NOTICE 級別可以檢查未初始化的變量。