在網頁應用程式上的安全漏洞，比例持續增加，除了源碼檢測之外，網頁應用程式防火牆和外掛在網站伺服器平臺的軟體也日漸受到企業的關注。
文章出處 www.bccs.com.tw 郵件
若有侵犯或不妥之處，尚祈來函告知，自當儘速取下。
文/楊啟倫 (記者) 2008-10-09
在網頁應用程式上的安全漏洞，比例持續增加，除了源碼檢測之外，網頁應用程式防火牆和外掛在網站伺服器平臺的軟體也日漸受到企業的關注。
開放原始碼的漏洞資料庫OSVDB（Open Source Vulnerability Database）發表的統計數據指出，從2005年開始，與網頁應用程式相關的漏洞占了所有已知漏洞的半數以上，而且持續增加，他們進一步預測，到了2008年，這類型的漏洞比例將會成長到接近66%的規模，使得企業網站成為駭客發動惡意攻擊的重要跳板。
網駭科技技術顧問李柏逸表示，從OWASP（Open Web Application Security Project）每年公布的10大漏洞排行榜來看，不單是構成網頁內容的原始碼，其他像是網頁伺服器本身，以及資訊人員所從事的不當設定，皆有可能導致資安風險的發生。
留意不同資安產品間的功能差別
為了解決網頁的安全問題，近年來企業開始導入網頁應用程式防火牆（Web Application Firewall，WAF）一類的資安產品，阻止駭客透過上述的幾種管道進行惡意攻擊。
李柏逸表示，WAF與企業內部常見的IPS（Intrusion Prevention System）在特徵碼，以及負向表列（黑名單）等多項功能上是相互重疊的，甚至有些廠商就直接取用IPS的功能模組來開發產品。舉例來說，F5的ASM（Application Security Manager）就很典型，它的負向表列源自Snort。
就功能而言，IPS可以當做WAF使用，不過對於一些經過編碼、加密（主要是HTTPS）過後的封包，IPS就不如「正牌」的WAF，能夠有效辨識封包內容；此外，由於IPS不具備正向表列的白名單機制，因此針對每家企業不同的網頁欄位設計時，也沒有辦法依照需求訂立專用的檢查規則，換句話說，實際用於網頁存取的連線檢查時，成效較為不彰。
必須啟用學習模式進一步強化產品防護能力
一般而言，WAF產品皆提供所謂的學習模式，藉以在正式上線、阻斷可疑的網頁連線之前，先根據企業網頁日常的存取行為，自行建立一個適用於這個網站的行為資料庫，降低誤判事件的發生機率。
學習模式開啟的時間長短，需視網站的規模大小而定，李柏逸說，根據實際協助企業導入WAF的經驗，一般來說，至少需要一個月的時間，才能讓WAF學習到較為完整的行為資料庫內容，如果像是網路銀行等規模較大，或者是對於安全防護有著更高需求的網站，則建議將學習模式運作的時間拉長到三個月，甚至更久。
WAF必須經過學習模式的步驟，才能將產品的防護效果藉由行為資料庫的建立而達到最佳化，李柏逸表示，過去他曾經遇過代理商在未經任何調校的情況下，直接讓產品上線運作。WAF的價格十分昂貴，既然企業花了大錢，就應該妥善運用，要求代理商提供一定的技術服務，將產品功能調整到符合自己所需的狀態。
行為資料庫內容的正確與否，攸關WAF防護能力的好壞，李柏逸建議，企業在導入初期可以採用「2 Arms」的架構放置WAF。他的意思是將開啟行為模式的WAF設置在網頁伺服器與資訊人員使用的個人端電腦之間，提供一些正常的存取行為，訓練設備學習，待行為資料庫建立完畢之後，再將WAF移至防火牆與網頁伺服器之間，以透通（Transparent）模式檢測所有存取網頁伺服器的連線。
有一點也十分重要，在WAF開啟學習模式之前，如果確定網站已經遭受攻擊，本身可能被置入一些有害的程式碼，這時就必須等到網頁內容清理完畢，才能開始部署產品。
軟體費用低，但硬體架構彈性較大
除了一般常見的硬體設備之外，WAF尚有軟體類型的產品（也稱之為主機型WAF）。和前者相比，軟體式的WAF具有價格便宜的好處（甚至有免費的開放原始碼產品），且能依據企業的需求去自訂功能，但代價是，這類產品必須安裝在網頁伺服器所在的電腦上，以外掛程式的型態運作，系統整體負荷較為吃重，而且一旦WAF出現問題，將可能同時造成網站服務的停擺，以及資料的流失。
相形之下，硬體設備是以透通方式放置在網頁伺服器的前端，較不容易發生上述情況，即便硬體運作出現故障，進出的封包還是可以採用Bypass的方式通過設備，後端的網頁伺服器服務不會受任何影響。
某些硬體的WAF具有支援網頁快取（cache）的功能，可以加快存取網頁的速度，如果先前有其他使用者曾經閱覽目前所要存取的網頁，那麼就可以採用反向代理（Reverse Proxy）的方式，直接從WAF讀取該網頁，不需連接到網頁伺服器。
需建立一套測試方法，才能客觀了解WAF產品能力
企業必須建立一套自己的測試方法，才能在眾多的WAF當中，找到符合本身需求的產品。李柏逸認為，廠商在測試這一類產品時，通常是採取對他們最有利的方式，不容易在沒有實際上線的情況下看出WAF能力所在。
弱點掃描是經常用來測試WAF的其中一種方式，但李柏逸表示，這個方法愈來愈不準確了，因為部分的WAF對於比較知名的滲漏工具做阻擋，因此掃出來的結果會很漂亮。
再加上，各家的WAF會彼此學習，時間一久在功能上就會變得差不多，很難由此分辨高下，真正的不同之處，在於安裝、設定這些產品的代理商，有些代理商的背景是以銷售網路設備為主，而某些則是長期從事資安攻防，對於如何防堵安全漏洞較有經驗，廠商代理的產品雖然相同，但是後者顯然在屬性上就比較適合協助企業導入。
[King：非常重要的觀念，請各位業務務必記起來]
功能雖然強大，但不是網頁安全的萬靈丹
雖然WAF可以針對網頁應用程式的漏洞，以及不當的設定提供相關的防護，但是對於所謂的商業邏輯漏洞，截至目前為止，仍然無法提供有效的防護，李柏逸表示，商業邏輯漏洞並非實際存在於網頁程式碼當中，而是網頁程式的一種「笨蛋設計」，利用網站運作機制不夠周全的地方，駭客可以從中鑽取漏洞，以不當的方式獲取利益。文⊙楊啟倫
2009年1月19日
妥善保護網頁應用程式的2種作法
Web Application Firewalls (WAF) - Have you deployed WAF technology?
"What is a Web Application Firewall?", Apologies but I respectfully defer you to the OWASP team who has a great definition posted at... If your first response to the subject is "What is a Web Application Firewall?", Apologies but I respectfully defer you to the OWASP team who has a great definition posted at: [http://www.owasp.org/index.php/Web_Application_Firewall]. For those who would like extended reading material into the subject of WAF technologies, refer to: [http://www.webappsec.org/projects/wafec/]. Opinion: Growth in the Web Application Firewall space may be attributed somewhat to changes in the Payment Card Industry's (PCI) Data Security Standard [https://www.pcisecuritystandards.org] where integration of an "Application layer firewall" [legacy term] or "Web Application firewall" technology previously listed as 'best practice' had been modified mid-2008 to become a requirement. WAF technology is now required tooling in the protection of public facing web applications especially where hosts are determined to be financially significant or financial data [credit card detail] is processed. I consider myself a geek in the art of WAF and place tremendous value on the visibility I gain into HTTP client traffic. I depend on client traffic visibility for threat/abuse discovery purposes combined with the mitigation capability afforded by WAF for the gratuitous stomping out badness. HTTP traffic visibility may seem trivial, until you contemplate the impossible if not an extreme PITA this becomes especially when HTTP services are SSL enabled. The deployment of traditional IDS sniffer mode detection capabilities are no longer suitable for identifying HTTP borne threats within SSL enabled web applications [aside from a few SSL negotiation flaws ;)] without significant expense and the operational changes required to enable IDS sensors with SSL payload visibility. Speaking from personal experience, I am a huge fan of ModSecurity [http://www.modsecurity.org]. ModSecurity while open-source is specific to Apache, and covers the lions share of web apps that I have responsibility in protecting. I do try to keep my eyes open for equivalent technologies that extend to other web server technology deployments where the underlying web server choice cannot be migrated for various reasons. While I have experimented with ModSecurity in reverse proxy mode to protect IIS and other server product hosted web services and web apps, I have a mix of IIS services that depend on Microsoft's URLScan filter to provide a subset of equivalent ModSecurity functionality. I have recently been turned onto to another open-source WAF named 'WebKnight' for Microsoft IIS server deployment. Based on available documentation it provides functionality that goes beyond basic URLScan features. However, my recent fifteen minute experiment in deploying WebKnight to a test environment was unsuccessful (I myself must RTFM), though I do plan on giving it proper evaluation time in the near future. I am most interested in hearing from readers on their experience with WAF technologies, whether they be open or commercial. I'm keenly interested in constructive product opinions, alternate solutions for server technologies not mentioned, your lessons learned, pitfalls or any success stories you are willing to share. If you happen to be doing something particularly exciting or know of other projects in the web application protection space that deserve attention, please share! Pending reader response, results may be posted to a future diary. ModSecurity : [http://www.modsecurity.org] Apologies in advance to all who like clickable URLs in their articles. It is my bit in avoiding the reinforcement of poor client user practices. William Salusky
文章出處:http://isc.sans.org/diary.html?storyid=5674&rss
若有侵犯或不妥之處，尚祈來函告知，自當儘速取下。
IIS UrlScan : [http://www.microsoft.com/downloads/details.aspx?FamilyId=EE41818F-3363-4E24-9940-321603531989&displaylang=en]
WebKnight : [http://www.aqtronix.com/?PageID=99]