網頁應用程式防火牆的興起─網管人員也能保障應用程式安全

 

	雷射槍要升級到多大火力才夠？ 「我們不是有買防火牆和入侵防禦系統了嗎？怎麼資料又被偷啦？」身處網管或資安部門的你，對這句話可能很熟悉吧？什麼，剛到部還沒聽過？那一年一度的技服中心資通安全攻防演練，絕對可以讓你對應用系統的無力感到震撼。傳統的網路安全解決方案多半偏向解決已知的系統問題：掃瞄作業系統弱點、稽核常用的Apache、Microsoft IIS網路伺服器問題、偵測利用phpbb漏洞的網蟲、阻擋針對Mambo弱點的攻擊程式，對這些威脅，現有的防禦機制都表現得十分優良。但有心的管理者可能會發現到一個盲點：這些防禦機制都是針對國際知名的軟硬體與系統，那我買的龍○風搜尋引擎怎麼辦？H○Search 網頁搜尋？M○2000電子郵件系統？我們自行撰寫的電子下單與網路銀行？請人開發的購物系統？要用哪套程式來幫它們找出弱點，要怎麼讓入侵防禦系統知道有人在攻擊它們呢？		即使是本土的入侵偵測設備產品， 也沒有專門為國內企業軟體撰寫防護特徵。
	兩面不是人的大門警衛 隨著時代改變，入侵系統、網站伺服器與公開的應用程式已經越來越難，駭客們逐漸轉向針對特定的網頁應用程式下手。以對岸最新一期的駭客雜誌《黑客防線》為例，遠端入侵手法與實例中，針對專屬網頁應用程式進行的攻擊超過八成（其中臺灣大學、北京大學與天津大學都貢獻了不少受害目標），制式的防禦機制完全無法進行攔截。而連續兩屆的臺灣駭客年會HITCON都發表了國內知名商用網頁系統漏洞。近期內網友們更架設起網站，專門揭露Blog網站的問題。		專門檢測Xuite系統安全強度的網站http://blog.xdite.net/， 其間也挾雜披露同型網站無名小站的問題。
	其實作過滲透測試的網管人員都知道，絕大多數漏洞都是程式開發時的疏忽所造成，雖然理論上只要修改程式就可以解決，但執行起來卻有不少困難：首先，研發人員或外包的開發商對於程式安全可能毫無概念，大部份的專科與大學都沒有教授過「安全程式寫作」課程。其次，研發人員或外包的開發商不願配合修改，因為時程、成本或技術問題，使得研發人員寧運花時間在保證程式的功能可用性，而拒絕處理安全上的需求。再者，即使開發完成，品保時多半缺乏安全性檢測機制與技術，無法驗證程式安全的可靠性。 為了解決這種問題，程式碼安全稽核軟體(Code Review)與網頁應用程式防火牆(WAF, Web Application Firewall)應運而生。程式碼安全稽核軟體直接針對程式進行檢查，找出可能會造成安全漏洞的地方。不過雖然現行針對C++、java的安全稽核技術都日趨成熟，但針對jsp、php、asp，甚至 SOAP/XML-RPC/Web Service 的稽核研究卻才剛起步，尚不足以應付現有惡劣環境。相較之下，針對網頁瀏覽行為進行防護的網頁應用程式防火牆，就成為網管人員的終極兵器了。
	除了看識別證外還要搜身 最陽春的網頁應用程式防火牆軟體版當屬UrlScan與Mod_Security。URLScan為微軟為IIS網頁伺服器所提供的保護機制，可由微軟網站免費取得。Mod_security模組則為Apache網頁伺服器提供了類似功能。使用者所送出的網頁要求會先經由主機上的UrlScan與Mod_Security檢查，再交由後端的網頁伺服器程式進行處理。管理者可設定UrlScan與Mod_Security內的參數，決定哪些網頁要求可以通過，哪些網頁要求必須拒絕，讓網頁伺服器不致因為處理到異常的網頁要求而發生問題。
	透過網頁應用程式防火牆來取得後端網頁。		硬體化之後，網頁應用程式防火牆的閘道式架構類似一個反向代理伺服器(Reverse Proxy)。所有使用者無法直接讀取到網頁主機，而是連接到網頁應用程式防火牆進行過濾後，再由網頁應用程式防火牆代理取得頁面傳回給使用者。網頁應用程式防火牆可以處理所有HTTP/ HTTPS/ SOAP/ XML-RPC/ Web Service協定，檢查使用者送出的網頁要求是否符合防火牆規則，再決定是否協助使用者取回網頁。檢查的內容包含網頁要求模式（HTTP Method）、所要求的網頁位址、所要求的網址參數、網頁餅乾（cookie）、所欲上傳的資料欄位等等，當所有項目都明列在防火牆規則所允許的項目中時，該網頁要求才被放行取得對應網頁。
	過濾網頁的資訊，不回傳給使用者。		反向代理伺服器架構的另一個好處，就是可以在網頁主機回傳資料時，同時檢查所回傳的頁面是否含有不可洩露的機密資訊，來決定是否回傳給使用者。舉凡明文密碼、電子郵件信箱、信用卡號碼、程式原始碼、系統與應用程式的錯誤訊息（駭客取得資料庫內容的主要來源之一）、資料表格等。無論是因為系統設計不良，或是後端程式運作異常而產生的資料外洩情事，都可倚賴網頁應用程式防火牆的雙向防禦機制來作為最終防線。
	在賓客名單中才可以進去 顧名思義，網頁應用程式防火牆就是針對網頁應用程式所設計的防火牆。與防毒程式或入侵偵測系統不同，網頁應用程式防火牆的重心不再只是找出惡意行為進行阻擋，而是利用正面表列直接控管使用者瀏覽網頁的行為。公司內的資安人員常常會煩惱一個問題，我們買的防毒軟體、入侵偵測系統的病毒與攻擊特徵碼要多久更新一次？是不是來得及更新？會不會不能更新？換版本要付多少錢？廠商要是倒了，誰來發布病毒與攻擊特徵碼？網頁應用程式防火牆就是為了迴避與駭客間的無止盡競賽，才導入了正面表列的控管原理。 傳統的封包過濾式防火牆是以來源位址、來源埠號、目標位址、目標埠號作為存取規則的判斷依據，網頁應用程式防火牆則是以網址要求、網站結構、瀏覽行為與網頁回應作為存取規則的限制標準。網頁應用程式防火牆先定義出正常的瀏覽流程，例如強迫使用者由特定頁面（例如首頁）進入網站、只允許使用者連接頁面內所顯示的超連結、用戶端只能回傳網頁表單內已定義的參數、或只能依照欄位格式輸入資料。當發現有任何未經定義或不符合存取規則的網頁要求時，網頁應用程式防火牆就拒絕該項網頁要求，以避免異常瀏覽行為可能造成的惡意影響。 舉例而言，網站開發人員線上修改網頁程式時，所使用的編輯程式經常會自動留下備份檔案。例如在UNIX環境下使用joe Editor編輯index.jsp，存檔時joe Editor會自動產生並儲存index.jsp~檔案，造成index.jsp與index.jsp~同時存在網頁目錄中。或在Windows環境下用UltraEditor編寫login.asp，網站上就會多了一個login.asp.bak檔案。當使用者刻意猜測http://www.target.com/index.jsp~，或http://www.target.com/login.asp.bak時，就可以直接看到原始程式碼，不僅可以直接翻找弱點，寫在程式裏的明文資料庫帳號密碼也被盜光光了。
	範例：管理人員沒注意到的pr_list.asp.bak遺留檔。		駭客瀏覽pr_list.asp.bak時，直接取得後端程式碼，並發現該網站的Access資料庫位置data/EG_catalog.mdb，也可以直接讓駭客下載。
	網頁應用程式防火牆可以設定只允許使用者從首頁開始瀏覽，並只能點選首頁上合法提供的連結；當瀏覽到第二頁時，也只能再繼續瀏覽第二頁所擁有的連結，這個方式叫作網址閉鎖（URL Closure）。前例中的pr_list.asp.bak與ata/EG_catalog.mdb就因為沒有正常網頁會提供連結指向這些檔案，所以即使管理者忘記將它們從伺服器上刪除，駭客也不能存取或下載這些檔案，因為防火牆只允許直接瀏覽首頁，而未開放直接瀏覽所有其他檔案。
	與應用程式跳黏巴達 與傳統防火牆相同，網頁應用程式防火牆必需依所保護的應用程式來作不同調整，以確保保護到每一個網頁與程式功能。網頁應用程式防火牆的最小保護單位不是每台主機或每個網站，而是應用程式（Application）本身。舉例而言，http://www.mysite.com/query 是提供給民眾的查詢系統，同一個網站上的http://www.mysite.com/sys/是只允許維護廠商登入的後台資料庫管理系統。管理者可以為兩個應用系統分別設置不同的防火牆規則：http://www.mysite.com/query不須遵守網址閉鎖，但禁止輸入任何SQL語法以避免民眾進行SQL中出（SQL Injection）攻擊；而http://www.mysite.com/sys/卻必須遵守網址閉鎖，但可以允許廠商直接在網頁管理系統中下達SQL命令管理資料庫。這兩個網域名稱相同的網站系統甚至可以透過網頁應用程式防火牆建置於不同的網路位址（IP）上，並由網路防火牆對不同的使用者來源進行限制。 因為網頁應用程式防火牆規則必需高度的客製化，因此導入時最需耗費心力的就是初始建置期。管理人員必需清楚了解組織的安全政策與網頁應用程式的結構，才能制定出完整的防護策略，但對現有網管人員的角色而言，卻有實際執行上的困難。為了協助管理者了解自己的網站使用狀況，現有的商用網頁應用程式防火牆都提供了自動學習機制。管理者在建置時可以先將規則調整得較為寬鬆，讓防火牆在實際環境下作業一段時間後，再依防火牆的學習建議加高限制。或反過來先將規則調整得嚴謹，阻擋所有未查明的活動，再視各種特例一一開放。 因為導入了正面表列的控管原理，網頁應用程式防火牆不再像防毒軟體或入侵防禦系統需要頻繁地升級與更新。除非後端網頁架後或頁面有大量變動，否則網頁應用程式防火牆的表列規則在初始設定完成之後，就不需要廿小時觀察與調整，大幅簡化了管理者的作業流程。初始建置期的長短端視網管人員對後端網頁應用程式的瞭解程度。對安全政策與網頁應用程式十分熟悉的管理者可以在一天內就完成所有設定，而需要藉助學習機制的管理者就可能需要一到二週的調整期。
	防火牆的未來願景：改邪歸正的防黑長城 網頁應用程式防火牆降低了網管人員與研發人員的溝通難度，直接保障了不安全程式的安全性。而在許多實作案例中，網頁應用程式防火牆甚至協助網管人員找出許多程式暇疵和管理疏忽，讓網管人員得以取得足夠資料提供給研發人員修正問題，協助主管修訂網路管理政策。 網站開發與網站保護權責的明確劃分，也擴展了網管人員安全控管能力，尤其是對主機代管業者而言，因為主機代管業者經常面對的大問題就是旁注攻擊法。旁注攻擊指的是利用同主機或同網域的其他網站進行入侵，進而影響到目標網站的方式。例如http://www.securesite.com/和http://www.insecuresite.com/雖然網域名稱不同，但都是位於同一台主機10.1.1.1上。雖然http://www.securesite.com/本身作的十分嚴謹的安全防護，但http://www.insecuresite.com/卻漏洞百出，當攻擊者入侵http://www.insecuresite.com/取得root權限後，http://www.securesite.com/設計得再安全也只是徒勞。 主機代管業者難以掌控後端所有客戶的網站設計；但當其中一位客戶的網站被侵入後，卻直接影響到同主機，甚至整個機房網段內的所有客戶網站。因此主機代管業者仿效了中國政府的防火長城概念，利用網頁應用程式防火牆來協助防護所有異質客戶的網頁內容。只要在流量許可的情形下，只要一套網頁應用程式防火牆就可以設定對多個不同的應用程式內容進行過濾與防禦，也可以依客戶需求調整不同的應用程式保護政策，而不需協調客戶更改後端程式。筆者在國內曾見過同時處理50個以上不同網站的網頁應用程式防火牆，國外甚至有高達上百個網站的防護案例。 同樣的安全問題也發生在大型組織或政府單位中，即使保障了自己的網站安全，卻不能保障下屬單位或上游單位不被入侵，間接影響自身網站。中國大陸建置了防火長城來管制網路言論，同樣的架構卻可以反其道而行，成為阻擋駭客的利器。網管單位利用網頁應用程式防火牆配合網路防火牆形成防黑長城，成為所有後端網站的統一入口，在不用一一監控與修改後端網頁應用程式的情況下，同時防禦所有站台。現在還苦於周旋於網站開發人員與駭客間的網管們，試試利用網頁應用程式防火牆來進行雙向防禦吧。
	國家級的防黑長城。
	參考資料 Web Application Security Consortium http://www.webappsec.org/ CGISecurity.net http://www.cgisecurity.com/questions/webappfirewall.shtml How To：使用 URLScan http://www.microsoft.com/taiwan/msdn/secmod/html/secmod114.mspx ModSecurity http://www.modsecurity.org/ Citrix Application Firewall (原Teros ) http://www.citrix.com/English/ps2/products/feature.asp?contentID=22719 Kavado InterDo Web Application Firewall http://www.kavado.com/products/interdo.asp F5 TrafficShield（原Watchfire AppShield） http://www.f5.com/products/TrafficShield/ NetContinuum Web Security Gateway http://www.netcontinuum.com/products/index.cfm