網站應用程式防火牆（Web Application Firewall，簡稱 WAF）是設於網站或網上應用程式前面的過濾層，會逐一檢查進入的網絡請求，在可疑請求到達應用程式之前加以攔截或標記。對於經營網店、預約系統或客戶平台的企業，WAF 可以多加一層防護，抵擋常見的網站攻擊；但它應與良好的程式碼、定期更新和監察一併使用，而不是取代它們。
WAF 做甚麼
每當有人開啟網頁、提交表格或呼叫 API，瀏覽器或應用程式都會發出一個 HTTP 請求。WAF 會讀取這些請求的內容，包括網址、標頭、Cookie 和表格欄位，再與一套規則比對。對每個請求，WAF 可以：
- 放行，讓請求如常到達網站
- 攔截，並顯示錯誤頁面
- 驗證，例如確認訪客是真正的瀏覽器
- 記錄，留待檢視而不攔截
規則通常有兩個來源：WAF 供應商維護的託管規則，針對廣為人知的攻擊類型；以及團隊為自己網站加設的自訂規則，例如限制同一地址嘗試登入的次數。
WAF 與網絡防火牆的分別
傳統的網絡防火牆按 IP 地址和連接埠等條件，決定哪些連線可以進入。它一般不會打開網絡請求的內容，判斷某次表格提交是否屬於攻擊。
WAF 在應用層運作。它假設網站流量本身是容許的，再檢查每個請求想做甚麼。大部分企業兩者都需要：網絡防火牆限制哪些服務可以從外部連接，WAF 則看守必須公開的服務所收到的流量。
WAF 可以幫上甚麼忙
- 常見的注入攻擊，例如藏在表格欄位或網址中的 SQL 注入和跨網站腳本（XSS）。
- 已知漏洞：廣泛使用的軟件一旦公開漏洞，WAF 供應商往往會加入規則，攔截已知的攻擊手法，這做法有時稱為「虛擬修補」。它可以在更新完成前降低風險，但不能代替更新。我們的 PHP2Shell 文章就是近期一例：供應商加入了防護規則，同時仍然要求客戶盡快修補。
- 自動化濫用，例如機械人不斷嘗試密碼、大量抓取網頁或提交垃圾表格，可以用流量限制和機械人驗證處理。
WAF 做不到的事
- 修正你自己程式碼的漏洞。如果已登入的客戶只要改動網址中的一個號碼，就能看到其他客戶的訂單，這個請求看來完全正常，WAF 通常會放行。
- 阻止使用被盜密碼的登入。這類登入與一般登入無異，多重身份驗證是更合適的措施。
- 保護可以被直接連接的伺服器。如果攻擊者找到源伺服器的地址並繞過 WAF，規則就不起作用。
- 無需調校就運作完美。規則太嚴會誤擋真正的客戶（誤報），太鬆則會讓攻擊通過。
WAF 的部署方式
- 雲端或邊緣 WAF：流量先經過供應商的網絡，再到達你的伺服器。這類服務常與內容傳遞網絡（CDN）一併提供，通常需要修改 DNS 設定。
- 雲端平台 WAF：附加在雲端主機的負載平衡器或閘道上。
- 伺服器或應用程式層面：網頁伺服器上的模組，或 CMS 內的安全插件。這類方案容易加裝，但與它所保護的網站在同一部伺服器上運行。
哪一種合適，視乎你的主機安排、預算和由誰管理。你的主機供應商或開發商可以說明現有方案已包括甚麼。
穩妥設定的要點
- 先用記錄或監察模式，檢視哪些請求會被攔截，再把規則改為攔截。
- 啟用規則後測試結帳、登入、表格和 API 呼叫，最好先在 Staging 環境測試。
- 在設定許可的情況下，限制源伺服器只接受來自 WAF 的流量。
- 繼續更新軟件和插件。WAF 只是爭取時間，並沒有消除漏洞。
- 把重要的 WAF 警報納入網站監察流程，並議定由誰跟進。
- 把 WAF 納入滲透測試範圍，了解它能擋住甚麼、擋不住甚麼。
可以向開發商或主機供應商問的問題
- 我們的網站前面有沒有 WAF？它正在攔截，還是只作記錄？
- 啟用了哪些規則？由誰負責更新？
- 如果客戶被誤擋，由誰處理？
- 源伺服器能否在不經 WAF 的情況下被連接？
- WAF 的檢視工作是否包括在我們的支援安排內？
如需一併檢視 WAF、主機和存取權限設定，可參閱 technine.io 的網絡安全及合規服務。
常見問題
小型企業網站需要 WAF 嗎？
任何設有登入、付款或表格的公開網站，不論規模，都可能成為自動化攻擊的目標。不少主機和 CDN 方案已包含基本的 WAF 功能，購買新服務前可先查看現有方案。
WAF 會令網站變慢嗎？
檢查請求需要額外處理，但設定得宜的 WAF 一般影響不大。與其假設，不如在啟用前後量度網頁速度。
有了 WAF，還需要更新和測試嗎？
需要。WAF 減低已知攻擊手法帶來的風險；更新修正的是漏洞本身，測試則找出通用規則無法辨認的問題。