由於網站攻擊成流，不安全的程式碼漏洞將導致網頁「包藏禍心｣，除了使用Core Review產品來協助修改程式碼之外，用作過濾、阻擋的網頁應用程式防火牆也就成了最快速提供解決方法的產品。

近來網頁應用程式防火牆可以說是依個相當熱門議題，各家大廠包括入侵防禦廠商、UTM廠商、負載平衡設備等紛紛推出相關解決方案，其原理與功能多有差異。

自網頁應用程式防火牆(WAF, Web Application Firewall)於05年進到台灣市場以來，由過去的每年約一家企業導入，到近年來每年約五家企業導入，WAF在台灣的市場正在逐漸走向他的巔峰期，Forrester Research的報告中呈現的是國外的市場規模，大略可推估出台灣市場約在07年的位置，預估尚有兩年持續向上攀升。而有此需求的企業多半是倚賴Web service甚深的線上購物、遊戲、網銀等，更由於該產品所費不貲，自然在台灣市場受到一些限制。此外，敦陽科技資安服務處資安顧問劉俊雄提到，近來由於政策使然，教育界對該類產品出現不少要求，這也是最初所沒有想到的。
備註：WAF採行的原理就是透過它的機過濾每一個HTTP Request，在內容龐大且瀏覽人數高的網站架構下使用，因此不免會存在效能瓶頸的問題

WAF選擇的正確觀念認親需求與限制

使用者在選擇WAF的時候，一來會有錯誤的認知，麟瑞科技產品應用開發處產品經理田習庸說，有些使用者其實也會搞不清楚自己的需求在哪，覺得WAF工具來測試，通常都是因為真正出過事情。若是在上線的狀況，當正常行為被擋下來時，就會有人反應出現異常或直接追蹤封鎖紀錄裡有沒有正常行為被誤判。但在測試過程中使用者通常怕會影響到線上服務，因此往往會被要求不要開封鎖功能，而只要單純的監控。在進行概念驗證(POC, Proof of concept)的過程中，因為沒有真正的攻擊者存在，就看不出效果，無法了解到實際物判率的狀況，一方面也因為網站過於複雜，一定會有比IPS還要高的誤判率，舉傳統的防火牆例子來說，擋掉常見的攻擊port然後其他全開，以及自己設定要開的port然後其他全關。這時候WAF是以黑白名單哪個為主？哪個為輔？這時就會出現差異性了，無論如何在佈署時如何透過學習降低誤判率就是一個導入WAF的大重點。

WAF定義及主要功能

而何謂網頁應用程式防火牆? IT人員或許知道卻不熟悉，有些管理階層甚至尚未聽過。簡單的說，他專門處理網頁上的流動控管，如HTTP以及HTTPS連線。除了可以透過單一硬體設備來佈建，亦可在建置在網站伺服器上運作，大部分WAF皆包括對 HTTP/HTTPS協定的強化、異常連線的過慮，其他的保護方式還包括了URL正規表示式和黑/白名單，其中，白名單功能雖會導致導入的複式雜度以及影響的效能，不過卻也提供良好的安全功能。此外還有紀錄部分的工作流程，像是依進出的HTTP/HTML以追蹤網站的存取行為，自動學習功能以自動自動更新安全政策，能夠防禦OWASP TOP10和SQL Injection、Cross Site Script等常見的多種網站入侵行為。

WAF可分成網路型硬體設備以及主機式軟體，前者為獨立出來的硬體設備，配置方式可有旁路監聽或在線佈署，後者則是將軟體安裝在原有的Web Server設備上，幾乎不用動到原有的網路架構，不過耗資的資源當然自於Web Server。動力安全資訊科技總監盧亞德說，大部分的SI會建議客戶導入硬體式WAF的原因是評估到風險問題，將軟體WAF裝設到客戶端，屆時可能會有責任劃分的問題，例如某些公司比較核心的伺服器都不允許裝代理程式了，更何況是WAF，應用程式跟應用程式之間共用某些DDL檔或Service Port衝突，當他沒有辦法證明部會受到影響時就只好先釐清、隔離，把不重要、不需要的先移除。而在營運上若很仰賴網站服務的企業，通常都會先考慮到將WAF建在網站伺服器上也會耗掉伺服器的資源，可能會造成網站伺服器不穩定等問題。不過若有成本或稽核考量的企業，泰半還是會選擇使用軟體式WAF，一台WAF硬體設備並不便宜，約要百萬新台幣，中小企業多半負擔不起。
註解：很多公司並不了解Web Application Firewall 與傳統網路防火牆的差異，一般防火牆是一個封包一個封包的觀測網路流量，而WAF卻是必須一次觀測許多封包，並且將所有的session都建立起模型以便於了解整體的網頁應用程式活動。

以功能上來考量，有幾家廠商是對HTTPS作即時分析並阻擋，這是因為內建SSL處理晶片，所以能夠直接做，而不至於影響效能，但純軟體式的就只能先放過，然後丟在buffer慢慢分析。

WAF的變化與組合-不同的附加價值

目前在WAF市場上，網路型硬體設備依然是較為主流且大宗的選擇，以下表格我們羅列一些目前市場常見的廠商。

如果我們要將WAF以功能特性來分，在不同產業裡，的確會有一些差異，但這些差異大的部份並不在WAF本身功能，而是端看它能夠結合的其他功能。我們可以看出幾種主要的類型：硬體式設備的有單純作WAF的產品，目前在台灣市場僅有Imperva，其有別於其他競爭對手之處其中有一是可以做資料庫的稽核，因此像是金融單位，可能會喜歡能夠同時做資料庫稽核的功能、整合；應用程式傳遞功能類的，例如網站多、大的企業，就可能需要同時作LB，入口網站或購物拍賣網站，可能會做更深入的應用程式傳遞需求；至於IPS/UTM裡的簡單WAF功能類，可能是極小的單位或缺乏IT資源、人力單位，使用UTM裡的部份模組功能，一倂達到小部份WAF需求；以及裝在網站伺服器主機、porxy server上的軟體式，可能適用中小型企業或網站伺服器數量少的單位；以及特殊的XML Firewall，則是應用在不一樣的場合，一般網路都是標準的HTTP/HTML，該產品針對Web service/XML，與WAF差異較大。

使用者測試經驗分享導入重點

一名資安人員跟我們分享他的經驗。「當初測到WAF是知道有這東西，想測試看看，注意的重點優先順序是：

1. 對現有網站效能影響，看看呈現出的結果。

2. 產品功能是否完整，是否真像系統整合商說的那麼天花亂墜?

3. 系統整合流程，看看真要搞這東西要花多久時間來準備。

4. 價格，報價當然也是個重點，因為那是唯一能拿出來何老大要錢買東西的籌碼阿!

由於WAF採行的原理就是透過它的機器去過濾每一個HTTP Request，在內容龐大且瀏覽人數高的網站架構下使用，因此不免會存在效能瓶頸的問題，在該名資安人員測試的結果下，儘管是測硬式WAF，在該公司的網站架構下依然效能不彰。他覺得網站是必須重視，也非常重要的一環，不過XSS、SQL Injection等等這些網頁弱點，在根本上還是要由網頁程式碼來改善，在寫Code時就應該把這些問題考慮進去，而不是在問題發生後才靠系統來檔。WAF是一種過渡時期的東西，是迫於現狀所產生的應急方案，對於眼下的網頁應用程式漏洞不見得能完全有效的阻絕掉。

儘管資安人員有此理念，但該公司的網頁應用程式開發工程師們顯得不怎麼配合，認為抵擋威脅是資安人員應當作的事，怎麼會把工作丟到程式開發上來? 如果程式開發人員不願意配合程式碼的改善，看來他所謂的過渡時期也不會太短。

最後該公司的結論，由於在前次測試遇到嚴重的效能瓶頸，所以最後採去的方式是透過code Review及內部自己定時的黑、白箱測試來降低網站若點威脅，透過該公司現有的人力資源運用上，來彌補這個問題，所以在評估後暫時不打算使用WAF這類產品。

然而他也坦承，資訊安全這東西誰都說不準，或許哪一天遇到某些安全事件排除不了，迫在眉睫之下的解決之道，也可以就真的只能將WAF的環境建置起來。

更由於Web Application Vulnerability是未來的趨勢，也是一塊市場大餅，目前WAF依然是唯一可以拿出來應急的解決方案。

從使用者經驗，可以看出幾個導入的重點：價格、效能、功能、報表。預算當然決定了一開始的大方向，若沒有充足的預算，能夠選擇的產品就很有限了，尤其是硬體式WAF的價格難免會讓人裹足不前，至少都要一兩百萬，一般企業通常會比較難一次買兩台來做HA(High Availability)或LB(Load Balance)。效能，產品能提供的佈署模式－reverse proxy、in-line、sniffer以及user「可以」佈署的模式，加起來是否能產生出最不影響Web service效能的條件。功能，產品名稱都冠上「WAF」，基本功能或許都有，但是做到的程度究竟有多少? 以及其由加價值，可搭配資料庫安全使用? 可在網路功能上做加值? 讓使用者寫入的規格具有彈性? 報表，有時候會有主觀上的偏好，或客觀的要求，例如有人有法規上的需求，選擇能夠立即產生符合法規需求報表的產品，使用者越省事，也有的只是單純想做一些統計、找出攻擊的來源或目標等等，因此只要透過客製化，將該產品的log匯出後再產生需求報表，亦能符合需求。

導入廠商技術能量 決定了WAF穩定與否

正由於各家廠商採用不同的架構、切入點去達到過濾、阻擋的目的，因此各家導入廠商如何有效運用產品，也成了導入成功與否的重要因素。不管是原廠商、經銷商或系統服務整合商，負責導入WAF的廠商，通常都占了成功與否的重要因素關鍵的七成左右，餘下三成則是使用這位使用者本身的條件，而當然，使用者在相關的技術層次上越不成熟，此時廠商專業與否則更顯其重要性。因此良好的廠商應當具備熟悉市面上現有的廠品設備之外，更需同時兼備了解web security的領域知識。

微調是WAF重要的關鍵，一般都會有維護上的問題，例如說誤檔或漏檔的時候該怎麼辦？這多半需靠人工合技術，當WAF沒有學習好得的話可能就會擋到，這時就需要一個懂得正規表示法(RE, Regular Expression)的人力來處理，例如說URL的後面接了一些參數，透過正規表示法來寫特徵碼，表現出哪些參數可以? 哪些不行? 除了要會正規表示法，同時也會看得懂攻擊手法，這些動作通常都是透過維護廠商來做，一來有其技術門檻，二來通常使用者也沒有時間學習或微調。

漢晰科技廠品技術經理蔡和燁提到，若買了很好的設備卻選錯維護商，就會無法發揮其功效。要看WAF是否穩定，跑的順不順，就知道廠商功力如何，假設網頁後台突然被擋住了，打電話請廠商處理，結果搞了半天或一整個下午才能用好，可能就是微調能力比較差，目前市場商各SI之間還是有一定的差異性存在，一般的SI都是裝機工程師，但如果是正規表示法，可以寫程式的，可能是較功力的。一般若MIS功力不錯的都可以先拿免費版的來試用，由於是開放原始碼，自然也有許多人提供特徵碼，不過要是通通都放進去，就會造成效能變差，而好的WAF雖然特徵碼不多，但大部分的主流攻擊都能夠阻擋掉，因此使用者也可以等到有預算或需求明確了再換更專業性的產品。

當WAF裝上去之後，就要讓他學習正常的網站作業流程，例如說跑一個正常的下訂單過程，這些自動學習到的成果就是白名單一部份，但亦有可能學習到錯誤的動作，因此要能適時的排除，雖然有經驗的廠商或許可以提供一些範本來修改，不過由於每家網站寫法不同，白名單依然會是客製化程度較高的部份，並不像黑名單依樣可功能以直接套用。一般來說白名單功能較強，雖然防禦效果較好，但是設定上也較複雜，因此若企業的資安能量，也就試IT人員技術較強可考慮選擇白箱為主比較好反之亦然。

而理論上白名單應該是要由甲方，也就是企業本身處理掉的。因為她們應該會比較熟悉自家網站的架構，但現實狀況多半是由SI廠商來處理。這時便是考驗SI導入經驗的時候了，有些使用單位環境單純，光是廠商提供的名單就很夠用了，而有些使用單位可能由於網路環境架構特殊，力然早期某些疊床架屋的網站架構可能作法是錯的，但已經沒辦法修了，只好維持現況，讓其他設備去配合。如此，在導入過程中較容易遇到誤判的情形，這時候就需要廠商根據經驗以及W3C分析的能力來協助找出問題點，並且做policy的修正。

由以上看來，要導入WAF的成功關鍵，還在於維護廠商是否具有良好的微調能力，確實發揮產品的功效。

　

【資料來源: 資安人】