網站、網上商店及企業 API 是企業連接客戶與業務系統的重要入口，但只要應用程式存在未修補漏洞，攻擊者便可能利用網站伺服器作為入侵起點。Cloudbric 於 2026 年 11 月 4 日發表的分析，以 PHP2Shell 漏洞為例，指出企業不能只依賴修補程式，亦需要以多層防禦降低漏洞被利用時的風險。

PHP2Shell 帶來甚麼風險？

Cloudbric 的文章指出，PHP2Shell 涉及兩項於 2026 年 10 月披露的 PHP 核心漏洞：CVE-2026-109618 及 CVE-2026-109619。在特定條件下，漏洞可能讓未經身份驗證的攻擊者執行遠端程式碼（Remote Code Execution，RCE）。這類漏洞值得關注，因為受影響的伺服器可能承載網站、客戶入口、內部系統或 API。

Cloudbric 引述 Amazon Threat Intelligence 的觀察，指相關漏洞在公開披露前已出現利用嘗試。對 IT 團隊而言，這反映漏洞管理有一個現實限制：由發現漏洞、確認受影響資產、測試修補程式，到安排正式部署，中間可能存在暴露時間。企業若只在收到公開通告後才開始盤點，便可能錯過最重要的應變窗口。

修補漏洞仍是首要工作，但不能只靠修補

面對 PHP2Shell，企業應先確認網站及應用程式所使用的 PHP 版本、執行環境、外掛與相依元件，再按照官方安全公告部署適用修補程式。若系統由外判開發商或託管服務商管理，亦應要求對方提供受影響範圍、修補時間及驗證結果。

修補程式處理的是已知軟件弱點，但網站仍可能面對 SQL Injection、跨站指令碼（XSS）、惡意機械人、自動化登入嘗試、異常 HTTP 請求及惡意 IP 流量。換言之，完成一次更新並不代表網站從此不會受到攻擊。企業需要同時維持漏洞管理、存取控制、日誌監察及網絡流量防護。

WAF 如何補上 Web 應用程式防線？

Web Application Firewall（WAF）會檢查進入網站的 HTTP 及 HTTPS 請求，並根據安全規則識別及阻擋可疑或惡意流量。它不能取代安全編碼、修補程式或伺服器加固，但可以在應用程式前方增加一層檢查，協助減少常見 Web 攻擊直接到達後端的機會。

對使用雲端服務及網上平台的企業，WAF 的價值在於可集中管理進站流量政策，並按網站、API 及業務風險調整規則。部署時仍要留意誤判、例外規則及應用程式更新，避免正常客戶交易或 API 呼叫被錯誤阻擋。

Cloudbric Managed Rules：按風險組合不同防護規則

Cloudbric 在文章中介紹 Cloudbric Managed Rules，讓企業按自身需要選擇及組合不同安全規則，以擴大 AWS WAF 的防護範圍。官方列出的規則類別包括：

• OWASP Top 10 Rule Set：針對常見 Web 應用程式風險提供規則基礎。
• Malicious IP Protection：識別及處理來自惡意 IP 位址的流量。
• Anonymous IP Protection：針對匿名網絡來源增加流量檢查。
• API Protection：為 API 流量加入相應防護規則。
• Bot Protection：協助處理自動化機械人流量。
• Tor IP Protection：識別來自 Tor 網絡的連線。
• Protocol Validity Protection：檢查 HTTP 通訊協定請求是否符合有效格式。

企業不宜單純把所有規則一次過開啟，而應先了解網站功能、客戶流量模式及現有應用程式限制，再以監察模式或測試環境評估規則效果。對登入、付款、搜尋及 API 等關鍵路徑，應特別測試正常請求與異常請求，並建立例外審批及回復程序。

企業可採用的五步應對流程

第一步：建立對外資產清單

盤點所有公開網站、子網域、API、測試環境及雲端負載，並記錄負責部門、系統擁有人、PHP 版本及託管供應商。沒有清單，就難以判斷漏洞通告是否與企業相關。

第二步：確認漏洞影響並優先修補

根據官方 PHP 安全公告及供應商指引，確認受影響版本與部署條件。優先處理直接連接互聯網、承載客戶資料或具有高權限的系統，並保留修補及驗證紀錄。

第三步：在 WAF 加入合適防護

檢視現有 WAF 規則是否涵蓋常見 Web 攻擊、惡意 IP、機械人及 API 風險。按業務需要選擇規則組合，並透過測試避免影響正常流量。

第四步：集中監察並保留事件紀錄

將 WAF 告警、Web 伺服器日誌、應用程式日誌及雲端平台事件互相對照。留意異常請求量、重複錯誤、可疑來源及不尋常的管理操作，並設定清晰的事件升級程序。

第五步：定期演練及檢視規則

以漏洞通告、攻擊模擬及應用程式更新作為演練情境，確認修補、封鎖、回復及通報流程能夠協同運作。每次系統版本或流量模式改變後，都應重新檢查 WAF 規則及誤判情況。

評估 WAF 方案時，買家應問甚麼？

• 方案支援哪些雲端 WAF 平台及部署方式？
• 規則更新由誰負責，更新頻率及變更通知如何安排？
• 能否按網站、API 或不同業務路徑選擇規則？
• 如何查看封鎖原因、告警及流量紀錄？是否方便匯出至現有 SIEM？
• 誤判時如何建立例外、審批及回復規則？
• 服務支援時間、事故升級方式及服務範圍是否符合企業要求？

結語：讓漏洞修補與流量防護互相配合

PHP2Shell 再次提醒企業，公開網站的風險不會只來自單一漏洞。修補程式負責處理軟件弱點，WAF 協助檢查及阻擋惡意請求，而存取控制、日誌監察及事件應變則負責補足其他環節。每一層都有其限制，亦正因如此，多層防禦比單一安全工具更適合面對不斷變化的 Web 威脅。

Cloudbric 表示，其服務伺服器在官方 PHP 安全修正發布後六小時內完成更新；這是供應商披露的自身應變紀錄。企業在選擇 WAF 或託管安全規則時，亦應要求供應商交代更新流程、規則維護、監察能力及支援責任，並以實際測試驗證防護效果。