2024 年 PHP 日本研討會

以 Apache 模組安裝

PHP 作為 Apache 模組使用時,它會繼承 Apache 的使用者權限(通常是「nobody」使用者的權限)。這對安全性和授權有幾個影響。例如,如果您使用 PHP 來存取資料庫,除非該資料庫具有內建的存取控制,否則您必須讓「nobody」使用者可以存取該資料庫。這表示惡意程式碼即使沒有使用者名稱和密碼也可以存取和修改資料庫。網路爬蟲程式完全有可能偶然發現資料庫管理員的網頁,並刪除所有資料庫。您可以使用 Apache 授權來防止這種情況,或者您可以使用 LDAP、.htaccess 檔案等設計自己的存取模型,並將程式碼包含在 PHP 程式碼中。

通常,一旦安全性建立到 PHP 使用者(在這種情況下,即 apache 使用者)幾乎沒有風險的程度,就會發現 PHP 現在被阻止寫入任何檔案到使用者目錄。或者它可能已被阻止存取或更改資料庫。它同樣也被保護,無法寫入好的和壞的檔案,或輸入好的和壞的資料庫交易。

此時經常犯的一個安全錯誤是允許 apache 擁有 root 權限,或以其他方式提升 apache 的能力。

將 Apache 使用者的權限提升到 root 非常危險,可能會危及整個系統,因此非安全專業人員不應考慮使用 sudo、chroot 或以 root 身分執行。

有一些更簡單的解決方案。透過使用 open_basedir,您可以控制和限制允許 PHP 使用的目錄。您也可以設定僅供 apache 使用的區域,將所有基於網頁的活動限制為非使用者或非系統檔案。

新增備註

使用者貢獻的備註 3 則備註

bk 2 at me dot com
12 年前
doc_root 已經限制了 apache/php 程式碼資料夾的位置。

open_basedir 更適合用於限制程式碼存取「不包含」程式碼的資料夾
可以是 doc_root 的子資料夾,如 php 文件範例 doc_root/tmp,但最好放在單獨的資料夾樹中,例如 ~user/open_basedir_root/。如果 doc_root(或 include_path)和 open_basedir 重疊,有害的程式碼可能會修改其他程式碼。
如果 apache/php 無法瀏覽 open_basedir 中的程式碼,即使惡意程式碼上傳了更多惡意程式碼到那裡,它們也將無法被瀏覽(執行)。

還應該注意的是,許多 shell 執行函式實際上是一種繞過 open_basedir 限制的方法,如果安全性需要嚴格的資料夾存取控制,則應停用這些函式。如果有害的程式碼被允許透過這些函式執行原生作業系統 shell 命令,它們就可以執行 unix/windows 版本的「delete */*/*/*」。作業系統 Shell 命令同樣可以透過強制複製檔案到 doc_root 樹中來繞過重新導向限制和檔案上傳限制。如果可以將它們作為一組或一類函式停用,那就太好了,但如果為了安全起見,仍然可以逐一停用它們。

備註:目前存在一個錯誤,如果執行了任何 include 或 require 陳述式,則將 open_basedir 設定為 docroot/tmp 的文件設定將無法運作。目前,如果 include 的 php 檔案不在 open_basedir 樹狀目錄和 doc_root+include_path 樹狀目錄中,則 include 將會失敗。這與安全性背道而馳。
這表示任何被 include 的 php 檔案都必須位於 open_basedir 中,因此容易受到有害腳本和 php 病毒(如 Injektor)的攻擊。
daniel dot eckl at gmx dot de
22 年前
有一個比在個別執行個體中啟動每個虛擬主機更好的解決方案,這樣可以避免浪費資源。

您可以為每個虛擬主機動態設定 open_basedir,這樣每個虛擬主機上的 PHP 腳本都會被限制在其文件根目錄中。

範例
<VirtualHost www.example.com>
ServerName www.example.com
DocumentRoot /www-home/example.com
[...]
<Location />
php_admin_value open_basedir \ "/www-home/example.com/:/usr/lib/php/"
</Location>
</VirtualHost>

如果您啟用安全模式 (safe_mode),則腳本只能使用指定目錄中的二進制檔案(建立一個僅包含客戶可能使用的二進制檔案的特殊目錄)。

現在,任何虛擬主機的使用者都無法讀取/寫入/修改您機器上其他使用者的資料。

Windseeker
joe
2 年前
對於一般使用者來說,如果沒有清楚地逐步列出解決問題的方法,那麼討論使用 PHP 時缺乏安全性的問題就沒有用。這些方法應該由 PHP 官方提供,而不是作為使用者的意見,然後再由其他使用者進行辯論。

我並不是反對辯論。這是我們作為一個開源社群學習的方式。然而,我們這些凡人需要 PHP 的大神們得出結論並提供最佳實務。
To Top