国产日韩综合一区二区性色av,欧美xxxx色视频在线观看

首頁

后端開發(fā)

php教程

框架和 CMS 中那些奇怪的 PHP 代碼

Barbara Streisand

Nov 12, 2024 am 07:56 AM

Ese extra?o código PHP en frameworks y CMS

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

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

<?php

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

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

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

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

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

<?php

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

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

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

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

<?php

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

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

直接啟動 PHP 文件的危險

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

當 PHP 錯誤暴露我們文件的路徑時，可能會出現(xiàn)危險。如果我們在服務(wù)器上配置了錯誤抑制，那么我們就不必擔心，并且即使沒有隱藏錯誤，暴露的信息也很少，只為可能的攻擊者提供一些線索。

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

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

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

注冊全局變量

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

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

<?php

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

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

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

這只是冰山一角，因為甚至可以用最小的努力進行更危險的攻擊。例如，在如下代碼中，程序員可以將其保留為未完成的腳本：

<?php

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

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

另一個示例：在名為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)用這個文件，從而嘗試從系統(tǒng)中刪除/etc/hosts文件（如果系統(tǒng)允許的話，或者其他）您有刪除權(quán)限的文件）。

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

<?php

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

現(xiàn)在，如果有人嘗試訪問remove_file.inc.php?filename=/etc/hosts，該常量將阻止訪問。它必須是一個常量，因為如果它是一個變量，攻擊者當然可以注入它。

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

但由于問題仍然存在，他們默認禁用它。即便如此，許多主機仍然繼續(xù)啟用它，因為擔心客戶的項目會停止工作，因為當時的大部分代碼沒有使用推薦的 HTTP_*_VARS 變量來訪問 GET/POST/... 值，但是而是全局變量。

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

今天使用

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

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

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

*register 全局變量的消失：從 PHP 5.4 開始，將 GET 和 POST 變量注冊為 PHP 全局變量的功能不再存在。正如我們所看到的，如果沒有 *register globals，單個腳本的執(zhí)行就變得無害，消除了這種做法的主要原因。
當前代碼中更好的設(shè)計：即使在 PHP 5.4 之前的版本中，現(xiàn)代代碼也經(jīng)過更好的設(shè)計，在類和函數(shù)中結(jié)構(gòu)化，這使得通過外部變量進行訪問或操作變得復(fù)雜。即使是經(jīng)常使用全局變量的 WordPress，也可以將這些風險降到最低。
*front-controllers的使用：如今，大多數(shù)Web應(yīng)用程序都使用精心設(shè)計的*front-controllers，這確保了類和函數(shù)的代碼僅當執(zhí)行鏈從主入口點開始時才被執(zhí)行。因此，如果有人嘗試單獨上傳文件并不重要：如果流程沒有從正確的點開始，邏輯將不會激活。
類自動加載：由于當前開發(fā)中使用了類自動加載，因此大大減少了 include 或 require 的使用。這意味著，除非您是新手開發(fā)人員，否則不應(yīng)存在可能帶來風險的 includes 或 requires（例如 遠程文件包含 或 本地文件包含)。
公共和私有代碼的分離：在許多現(xiàn)代CMS和框架中，公共代碼（例如資產(chǎn)）與私有代碼（編程代碼）分離。此措施特別有價值，因為它可以確保如果 PHP 在服務(wù)器上失敗，PHP 文件中的代碼（無論它們是否使用常量技術(shù)）不會暴露。盡管這并不是專門為了緩解注冊全局變量而實施的，但它有助于避免其他安全問題。
友好 URL 的擴展使用：如今，將服務(wù)器配置為使用友好 URL 很常見，這總是強制使用單個入口點進行編程。這使得任何人幾乎不可能單獨上傳 PHP 文件。
抑制生產(chǎn)中的錯誤輸出：大多數(shù)現(xiàn)代 CMS 和框架默認都會阻止錯誤輸出，因此攻擊者無法找到有關(guān)應(yīng)用程序內(nèi)部工作原理的線索，這可能會促進其他類型的錯誤輸出攻擊。

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