PHP 日本研討會 2024

PHP 安全性注意事項

PHP 是一個強大且彈性的工具。這種強大和彈性來自於 PHP 是一個非常精簡的框架,建立在數十個不同的第三方函式庫之上。每個函式庫都有其獨特的輸入資料特性。對一個函式庫來說可能安全的資料,對另一個函式庫來說可能並不安全。

很久以前,一個名為 NeverEverSanity 的網路蠕蟲暴露了熱門 phpBB 留言板應用程式中輸入驗證的一個錯誤。他們的重點程式碼沒有正確處理雙重 URL 編碼的輸入。如果沒有對不受信任的使用者資料進行適當的輸入驗證,再加上任何可以執行程式碼或寫入檔案系統的 PHP 呼叫,您就會產生潛在的安全問題。儘管對於一些不相關的 PHP 安全性修復程式和 NeverEverSanity 蠕蟲的時間安排有些混淆,但該蠕蟲實際上與 PHP 中的安全問題無關。

當我們談論網路應用程式中的安全性時,我們實際上分為兩類。遠端和本機。每一個遠端攻擊都可以透過非常仔細的輸入驗證來避免。如果您正在編寫一個要求使用者姓名和年齡的應用程式,請檢查並確保您只收到您期望的字元。同時確保您不會收到太多可能會溢出您的後端資料儲存或您可能將此資料傳遞給的任何操作函數的資料。遠端攻擊的一個變體是 XSS 或跨網站指令碼問題,其中一個使用者輸入一些 JavaScript,然後下一個使用者會看到這些 JavaScript。

對於本機攻擊,我們主要聽到的是關於共用虛擬主機上的 open_basedir 問題。此功能是為了方便系統管理員而存在的,絕不應被視為一個完整的安全框架。由於您可以連接到 PHP 的所有第三方函式庫,以及您可以欺騙這些函式庫存取檔案的所有創造性方式,因此無法保證此指令的安全性。例如,Oracle 和 Curl 擴充功能都有透過函式庫讀取本機檔案的方法。除了修改這些第三方函式庫(對於閉源的 Oracle 函式庫來說會很困難)之外,PHP 實際上對此無能為力。

當您單獨使用 PHP,只有一小組擴充功能時,open_basedir 通常足以使一般的壞人感到沮喪,但對於關鍵的安全情況,您應該使用作業系統層級的安全性,方法是運行多個 Web 伺服器,每個伺服器都有自己的使用者 ID,理想情況下是在單獨的 jailed/chroot'ed 檔案系統中。更好的是,使用完全獨立的實體伺服器。如果您與不信任的人共用伺服器,您需要意識到您永遠無法實現滴水不漏的安全性。

To Top