注意：要閱讀這篇文章，我們假設(shè)您具有最低限度的 PHP 編程知識(shí)。

這篇文章是關(guān)于 PHP 代碼片段的，您可能在您最喜歡的 CMS 或框架的頂部看到過該代碼片段，并且您可能已經(jīng)讀過，為了安全起見，您應(yīng)該始終將其包含在您所使用的所有 PHP 文件的標(biāo)頭中。發(fā)展，盡管沒有非常清楚地解釋原因。我指的是這段代碼：

<?php

if ( ! defined( 'ABSPATH' ) ) {
    exit; // Exit if accessed directly
}

這種類型的代碼在 WordPress 文件中很常見，盡管它實(shí)際上出現(xiàn)在幾乎所有框架和 CMS 中。例如，在 CMS Joomla 的情況下，唯一改變的是使用 JEXEC，而不是 ABSPATH。否則，邏輯是相同的。這個(gè) CMS 源于另一個(gè)名為 Mambo 的 CMS，它也使用類似的代碼，但使用 _VALID_MOS 作為常量。如果我們追溯到更遠(yuǎn)的時(shí)間，我們會(huì)發(fā)現(xiàn)第一個(gè)使用這種類型代碼的 CMS 是 PHP-Nuke（被一些人認(rèn)為是第一個(gè) PHP CMS）。

PHP-Nuke（以及當(dāng)今大多數(shù) CMS 和框架）的執(zhí)行流程包括順序加載多個(gè)文件，這些文件一起響應(yīng)用戶或訪問者在網(wǎng)絡(luò)上執(zhí)行的操作。也就是說，想象一下當(dāng)時(shí)的網(wǎng)站，位于 example.net 域下并安裝了此 CMS。每次加載主頁時(shí)，系統(tǒng)都會(huì)有序地執(zhí)行一系列文件（這里只是一個(gè)示例，而不是真正的序列）：index.php => load_modules.php =>;模塊.php。也就是說，按照這個(gè)順序，首先加載index.php，然后該腳本加載load_modules.php，然后加載modules.php。

這個(gè)執(zhí)行鏈并不總是從第一個(gè)文件（index.php）開始。事實(shí)上，任何人都可以通過直接通過 URL 調(diào)用其他 PHP 文件之一（例如 http://example.net/load_modules.php 或 http://example.net/modules.php）來跳過此流程的一部分，這正如我們將看到的，在許多情況下可能是危險(xiǎn)的。

這個(gè)問題是如何解決的？引入了安全措施，在每個(gè)文件的開頭添加代碼，類似于：

<?php

if (!eregi("modules.php", $HTTP_SERVER_VARS['PHP_SELF'])) {
    die ("You can't access this file directly...");
}

基本上，這段代碼位于一個(gè)名為modules.php 的文件的標(biāo)頭中，用于檢查是否可以通過URL 直接訪問modules.php。如果是這樣，執(zhí)行將停止，并顯示消息：“您無法直接訪問此文件...”。如果$HTTP_SERVER_VARS['PHP_SELF']不包含modules.php，那么這意味著我們處于正常的執(zhí)行流程中并被允許繼續(xù)。

但是，此代碼有一些限制。首先，插入的每個(gè)文件的代碼都不同，這增加了復(fù)雜性。另外，在某些情況下，PHP 沒有為 $HTTP_SERVER_VARS['PHP_SELF'] 賦值，這限制了其有效性。

那么開發(fā)者做了什么？他們用更簡單、更高效的版本替換了所有這些代碼片段：

<?php

if ( ! defined( 'ABSPATH' ) ) {
    exit; // Exit if accessed directly
}

在 PHP 社區(qū)中已經(jīng)很常見的這段新代碼中，驗(yàn)證了常量的存在。該常量在流程的第一個(gè)文件（index.php 或 home.php 或一些類似文件）中定義并分配了一個(gè)值。因此，如果該常量不存在于流中的其他文件中，則意味著有人跳過了 index.php 文件并嘗試直接訪問另一個(gè)文件。

直接啟動(dòng) PHP 文件的危險(xiǎn)

此時(shí)你肯定會(huì)想，打破執(zhí)行鏈一定是世界上最嚴(yán)重的事情。然而，現(xiàn)實(shí)情況是，通常，它并不代表重大危險(xiǎn)。

當(dāng) PHP 錯(cuò)誤暴露我們文件的路徑時(shí)，可能會(huì)出現(xiàn)危險(xiǎn)。如果我們?cè)诜?wù)器上配置了錯(cuò)誤抑制，那么我們就不必?fù)?dān)心，并且即使沒有隱藏錯(cuò)誤，暴露的信息也很少，只為可能的攻擊者提供一些線索。

也可能有人訪問包含 HTML 片段（來自視圖）的文件，從而泄露其部分內(nèi)容。在大多數(shù)情況下，這也不應(yīng)該令人擔(dān)憂。

最后，開發(fā)人員可能由于疏忽或缺乏經(jīng)驗(yàn)而在執(zhí)行流程中插入沒有外部依賴的危險(xiǎn)代碼。這是非常不尋常的，因?yàn)橥ǔ？蚣芑?CMS 的代碼依賴于其他類、函數(shù)或外部變量來執(zhí)行。因此，如果您嘗試直接通過 URL 運(yùn)行腳本，它將無法找到這些依賴項(xiàng)，并且不會(huì)繼續(xù)執(zhí)行。

那么，如果幾乎沒有任何值得擔(dān)心的地方，為什么要添加常量代碼呢？原因是這樣的：“此方法還可以防止通過攻擊 注冊(cè)全局變量 進(jìn)行意外的變量注入，從而防止 PHP 文件假設(shè)它實(shí)際上不在應(yīng)用程序內(nèi)部。”

注冊(cè)全局變量

自 PHP 誕生以來，所有通過 URL (GET) 或表單 (POST) 發(fā)送的變量都會(huì)自動(dòng)轉(zhuǎn)換為全局變量。也就是說，如果文件 download.php?filepath=/etc/passwd 被訪問，則在 download.php 文件中（以及在執(zhí)行流程中依賴于該文件的文件中）可以使用 echo $filepath ；結(jié)果將是 /etc/passwd。

在 download.php 中，無法判斷 $filepath 變量是否是由執(zhí)行流程中的前一個(gè)文件創(chuàng)建的，或者是否有人通過 URL 或 POST 欺騙了它。這產(chǎn)生了很大的安全漏洞。讓我們看一個(gè)例子，假設(shè) download.php 文件包含以下代碼：

<?php

if ( ! defined( 'ABSPATH' ) ) {
    exit; // Exit if accessed directly
}

開發(fā)人員可能考慮過使用前端控制器模式來實(shí)現(xiàn)他的代碼，即讓所有 Web 請(qǐng)求都通過單個(gè)輸入文件（index.php、home.php 等）。該文件將負(fù)責(zé)初始化會(huì)話、加載公共變量，最后將請(qǐng)求重定向到特定腳本（在本例中為 download.php）以下載文件。

但是，攻擊者可以通過簡單地調(diào)用 download.php?filepath=/etc/passwd 來繞過計(jì)劃的執(zhí)行序列，如前所述。因此，PHP 會(huì)自動(dòng)創(chuàng)建全局變量 $filepath，其值為 /etc/passwd，從而允許攻擊者從系統(tǒng)下載該文件。嚴(yán)重錯(cuò)誤。

這只是冰山一角，因?yàn)樯踔量梢杂米钚〉呐M(jìn)行更危險(xiǎn)的攻擊。例如，在如下代碼中，程序員可以將其保留為未完成的腳本：

<?php

if (!eregi("modules.php", $HTTP_SERVER_VARS['PHP_SELF'])) {
    die ("You can't access this file directly...");
}

攻擊者可以使用遠(yuǎn)程文件包含 (RFI) 攻擊執(zhí)行任何代碼。因此，如果攻擊者在自己的網(wǎng)站 https://mysite.net 上創(chuàng)建了一個(gè) My.class.php 文件，其中包含他想要執(zhí)行的任何代碼，他就可以通過將其域傳遞給易受攻擊的腳本來調(diào)用該腳本：codigo_inutil.php?base_path= https://mysite.net，攻擊完成。

另一個(gè)示例：在名為remove_file.inc.php 的腳本中，包含以下代碼：

<?php

if (!defined('MODULE_FILE')) {
    die ("You can't access this file directly...");
}

攻擊者可以使用像remove_file.inc.php?filename=/etc/hosts這樣的URL直接調(diào)用這個(gè)文件，從而嘗試從系統(tǒng)中刪除/etc/hosts文件（如果系統(tǒng)允許的話，或者其他）您有刪除權(quán)限的文件）。

在像 WordPress 這樣內(nèi)部也使用全局變量的 CMS 中，這種類型的攻擊是毀滅性的。然而，由于不斷的技術(shù)，這些和其他 PHP 腳本受到了保護(hù)。讓我們看最后一個(gè)例子：

<?php

if ( ! defined( 'ABSPATH' ) ) {
    exit; // Exit if accessed directly
}

現(xiàn)在，如果有人嘗試訪問remove_file.inc.php?filename=/etc/hosts，該常量將阻止訪問。它必須是一個(gè)常量，因?yàn)槿绻且粋€(gè)變量，攻擊者當(dāng)然可以注入它。

此時(shí)您可能想知道如果 PHP 如此危險(xiǎn)，為什么還要保留此功能。另外，如果你了解其他腳本語言（JSP、Ruby 等），你會(huì)發(fā)現(xiàn)它們沒有類似的東西（這就是為什么它們也不使用常量技術(shù)）。讓我們記住，PHP 是作為 C 語言的模板系統(tǒng)誕生的，這種行為促進(jìn)了開發(fā)。好消息是，看到它造成的問題，PHP 維護(hù)者決定在 php.ini 中引入一個(gè)名為 register_globals 的指令（默認(rèn)激活）以允許禁用此功能。

但由于問題仍然存在，他們默認(rèn)禁用它。即便如此，許多主機(jī)仍然繼續(xù)啟用它，因?yàn)閾?dān)心客戶的項(xiàng)目會(huì)停止工作，因?yàn)楫?dāng)時(shí)的大部分代碼沒有使用推薦的 HTTP_*_VARS 變量來訪問 GET/POST/... 值，但是而是全局變量。

最后，看到情況沒有改變，他們做出了一個(gè)重大決定：在 PHP 5.4 中消除這個(gè)功能，以避免所有這些問題。因此，如今，像我們看到的腳本（不使用常量）不再通常構(gòu)成危險(xiǎn)，除了在某些情況下出現(xiàn)一些無害的警告/通知。

今天使用

時(shí)至今日，持續(xù)技術(shù)仍然很常見。然而，令人悲傷的是——也是導(dǎo)致這篇文章的原因——很少有開發(fā)人員知道其使用的真正原因。

與過去的其他良好實(shí)踐一樣（例如將函數(shù)中的參數(shù)復(fù)制到局部變量以避免調(diào)用中引用的危險(xiǎn)，或者在私有變量中使用下劃線來區(qū)分它們），許多人仍然應(yīng)用它只是因?yàn)橛腥嗽?jīng)告訴他們這是一個(gè)很好的做法，而沒有考慮它是否真的在當(dāng)今時(shí)代增加了價(jià)值?，F(xiàn)實(shí)情況是，在大多數(shù)情況下，不再需要此技術(shù)。

這種做法失去相關(guān)性的一些原因如下：

• *register 全局變量的消失：從 PHP 5.4 開始，將 GET 和 POST 變量注冊(cè)為 PHP 全局變量的功能不再存在。正如我們所看到的，如果沒有 *register globals，單個(gè)腳本的執(zhí)行就變得無害，消除了這種做法的主要原因。

• 當(dāng)前代碼中更好的設(shè)計(jì)：即使在 PHP 5.4 之前的版本中，現(xiàn)代代碼也經(jīng)過更好的設(shè)計(jì)，在類和函數(shù)中結(jié)構(gòu)化，這使得通過外部變量進(jìn)行訪問或操作變得復(fù)雜。即使是經(jīng)常使用全局變量的 WordPress，也可以將這些風(fēng)險(xiǎn)降到最低。

• *front-controllers的使用：如今，大多數(shù)Web應(yīng)用程序都使用精心設(shè)計(jì)的*front-controllers，這確保了類和函數(shù)的代碼僅當(dāng)執(zhí)行鏈從主入口點(diǎn)開始時(shí)才被執(zhí)行。因此，如果有人嘗試單獨(dú)上傳文件并不重要：如果流程沒有從正確的點(diǎn)開始，邏輯將不會(huì)激活。

• 類自動(dòng)加載：由于當(dāng)前開發(fā)中使用了類自動(dòng)加載，因此大大減少了 include 或 require 的使用。這意味著，除非您是新手開發(fā)人員，否則不應(yīng)存在可能帶來風(fēng)險(xiǎn)的 includes 或 requires（例如 遠(yuǎn)程文件包含 或 本地文件包含)。

• 公共和私有代碼的分離：在許多現(xiàn)代CMS和框架中，公共代碼（例如資產(chǎn)）與私有代碼（編程代碼）分離。此措施特別有價(jià)值，因?yàn)樗梢源_保如果 PHP 在服務(wù)器上失敗，PHP 文件中的代碼（無論它們是否使用常量技術(shù)）不會(huì)暴露。盡管這并不是專門為了緩解注冊(cè)全局變量而實(shí)施的，但它有助于避免其他安全問題。

• 友好 URL 的擴(kuò)展使用：如今，將服務(wù)器配置為使用友好 URL 很常見，這總是強(qiáng)制使用單個(gè)入口點(diǎn)進(jìn)行編程。這使得任何人幾乎不可能單獨(dú)上傳 PHP 文件。

• 抑制生產(chǎn)中的錯(cuò)誤輸出：大多數(shù)現(xiàn)代 CMS 和框架默認(rèn)都會(huì)阻止錯(cuò)誤輸出，因此攻擊者無法找到有關(guān)應(yīng)用程序內(nèi)部工作原理的線索，這可能會(huì)促進(jìn)其他類型的錯(cuò)誤輸出攻擊。

盡管在大多數(shù)情況下不再需要此技術(shù)，但這并不意味著它永遠(yuǎn)沒有用處。作為一名專業(yè)開發(fā)人員，必須分析每種情況并確定持續(xù)技術(shù)是否與您工作的特定環(huán)境相關(guān)。這是您應(yīng)該始終遵循的標(biāo)準(zhǔn)，即使在您認(rèn)為良好的實(shí)踐中也是如此。

疑問？這里有一些提示

如果您仍然不確定何時(shí)應(yīng)用持續(xù)技術(shù)，這些建議可以指導(dǎo)您：

• 如果您認(rèn)為您的代碼可以在早于 5.4 的 PHP 版本上運(yùn)行，請(qǐng)始終使用該技術(shù)。
• 如果文件僅包含類的定義，請(qǐng)不要使用它。
• 如果文件僅包含函數(shù)，請(qǐng)勿使用它。
• 如果文件僅包含 HTML/CSS，請(qǐng)勿使用，除非 HTML 公開了某種類型的有價(jià)值信息。
• 如果文件僅包含常量，請(qǐng)勿使用它。

對(duì)于其他一切，如果您有疑問，請(qǐng)應(yīng)用它。在大多數(shù)情況下，它不應(yīng)該是有害的，并且可以在意外情況下保護(hù)您，特別是如果您剛剛開始。隨著時(shí)間和經(jīng)驗(yàn)的積累，您將能夠更好地評(píng)估何時(shí)應(yīng)用此技術(shù)和其他技術(shù)。

繼續(xù)學(xué)習(xí)...

• register_globals - MediaWiki
• PHP：使用寄存器全局變量 - 手冊(cè)
• 遠(yuǎn)程文件包含漏洞 [LWN.net]
• Bugtraq：Mambo Site Server 版本 3.0.X 中存在嚴(yán)重安全漏洞

以上是框架和 CMS 中那些奇怪的 PHP 代碼的詳細(xì)內(nèi)容。更多信息請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！