Web應用安全掃描逐漸升溫 職業人士來說WASS評估標準
WASS全稱是Web Application Security Scanner，中文翻譯即是Web應用安全掃描器。說白一點就是Web漏洞掃描軟件，國外的產品有IBM Appscan、HP WebInspect、Acunetix Web Security Scanner等；國內的產品有JSky、Matrixy、WebRavor等。目前WASS也是逐步升溫，廠家也是越來越多。
WASS被廣泛關注是有背景的：一來是原有網絡和系統漏洞的減少，許多“有志之士”將目標轉向了Web應用程序，伴隨著大量的SQL注入蠕蟲掛馬以及由社交網站的XSS蠕蟲出現，業界對Web應用安全也是越來越重視；二來，未來的技術趨勢也是越來越向Web平臺遷移，比如微軟和GOOGLE都向網絡應用程序和網絡操作系統方面演進，這些都是戰略性的；最后，從廠商角度來說，利益的驅動還是比較大的，這主要是源自IBM上億美金收購Watchfire和HP上億美金收購spidynamics的這幾次大手筆。不只是WASS關注度很大，WAF的發展也是很迅速的，不過關于WAF的內容在這里暫且不表。
很長一段時間以來，Web應用安全掃描工具的市場基本都是國外的廠商壟斷，國內缺少自動化的評估工具，啟明星辰，綠盟等國內少數的幾家具有一定規模的廠商在進行安全評估時很大程度上依賴于安全專家，這其實也是有利有弊。因為安全評估不像滲透測試，滲透測試只要找準點攻破目標系統就行；安全評估則在保證有效的情況下還得保證全面性。在這個過程中，人的精力畢竟是有限的，小網站還好，要是來個大網站，上萬個目錄頁面，人力成本是很高的。
再換句話說，即使在有充足的人力成本情況下，你就能保證安全評估工程師不會出現重復勞動下的疲憊或者遺漏？從服務商角度而言也是如此，一個成指數增長（資源增長遠小于客戶數增長）的企業才是個好企業，一個依賴大量的專家來保持增長的企業就很難想象有多大的發展空間了。再說了，在國內有那么多稱職的安全專家？總之，WASS的出現是符合市場需求的，市場就這么起來了，因此國內這幾年也出現了像諾賽科技、安域領創還有安恒科技等公司。好歹WASS的市場也呈現百花齊放的景象，越來越多的公司正在加入這個行業。
新的問題就來了，如此多的WASS，如何保證主要功能的完整性呢？或者說對于一個客戶而言，如何確保購買的WASS是能夠有效的全面的找出系統中的漏洞呢？我們姑且可以認為幾個處于霸主地位的WASS廠商也是這么為客戶著想的，他們在Web Application Security Consortium的組織下，于一個漆黑的夜晚一個漆黑的小屋內小聲的討論，完成了一份“Web Application Security Scanner uation Criteria”，也就是Web應用安全評估標準，下文中均簡寫為WASSEC。（稍微遺憾的是，里面沒有一個中國廠商參與）
WASSEC可以通過如下地址下載（部分國內用戶可能不太方便訪問）：http://projects.webappsec.org/f/Web+Application+Security+Scanner+uation+Criteria+-+Version+1.0.pdf，共分為如下幾個大章節：
1、 協議支持
2、 認證
3、 會話管理
4、 鏈接分析
5、 解析
6、 測試
7、 命令和控制
8、 報表
#p#
9、 附錄A：考慮購買掃描器時的建議
內容寫的比較細，這里并不一一細數，我們也不用太陷入里面的章節。可以從如下框架理解，因為一個WASS無非是滿足這些框架功能的組合體：
a. 網頁爬蟲：評價WASS一個很重要的因素來自于鏈接分析能力，如是否支持從Javascript中提取鏈接，是否支持從flash文件中提取鏈接，是否支持從復雜的ajax應用中提取鏈接等等。另外也包括標簽的事件，重定向請求等。至于認證和協議都是非常基礎的，缺少這些的我們甚至可以理解它壓根就不是一個WASS。
b. 安全測試：WASS是否有效的核心模塊來自于漏洞的分析能力。支持的漏洞種類（SQL注入，跨站腳本，信息泄露等）是否齊全，是否能夠準確分析誤報（如自定義404頁面等），是否支持權限測試等等。
c. 報表：對于采購WASS的用戶而言，一份漂亮的報表是必不可少的。是否包含漏洞描述，解決建議；是否滿足業界的安全標準（如OWASP TOP 10,薩班斯法案等，這些老外很看重）；是針對開發者還是測試人員；是否支持PDF,HTML格式等等
d. 操作性：對于自動話工具而言，越少的操作達到越大的效果是很重要的，因此像掃描操作，暫停操作等是必須的；同時應當能夠及時顯示進度，查看已經發現的漏洞細節等。
如果您是一位經常關注Web應用安全的朋友，應該會有一個感覺，這個WASSEC里面有點貓膩。向來咱們中國人都是屬于那種悶聲做事的那種，尤其對于負責技術的人員而言，對于沒有親眼見著的事情持有很強烈的反對態度。假設我們把場景放在測試人員用工具掃描完然后將漏洞遞交給開發人員的時候，開發人員說“這怎么會是漏洞呢，我們一直都是這么操作的啊”，如果這位可憐的測試人員在安全方面不是比較精通的話就很麻煩了。
事實上這種情況并不少見。在我東塔亮看來，合格的WASS必須具備滲透測試功能，否則很難去解釋這為什么是個漏洞了。巧的很，咱們國內的WASS廠商都具備這個功能，JSky就不用說了，搭配了包含Pangolin和IISPUTScanner在內的一系列用于滲透測試的模塊，在Matrixy和Webravor中也內置了SQL注入滲透測試模塊。而這些剛好是國外的WASS中都沒有的。看來黑燈下火關門討論的成果也不是太全面。至少不符合少數滲透測試人員的需求；）
對于本地化來說的話，在WASSEC中也沒有提及到。國內的市場需要有本地化語言，這在一些大型采購單位基本都是硬性規定。國內的WASS廠商做的都還比較好。國外的就差遠了，像IBM的Appscan采用了自動化的翻譯軟件翻譯出來的語言看起來真是別扭的不行，不過總比沒有好，其他廠商的就不說了。
除了本身軟件本地化的問題以外，對于編碼的支持也是國外WASS所不具備的。比如說，在WASSEC中明確提出了ISO-8859-1、UTF-7、UTF-8、UTF-16編碼，對于包括GB2312編碼在內的所有東亞或者西歐的編碼方式均沒有提到，這也就是為什么在國外WASS的一些報表中出現大量亂碼的原因。
目前大量網站的表單認證都是帶有驗證碼的，對于一個WASS而言，如何能夠繞過驗證碼繼續掃描是一個很重要的技術細節，在WASSEC中也沒有提及，我想這是因為與會者所在的那些廠商的產品均不具備這個功能導致的吧。這也是能理解，但是，你們沒有，不代表別人沒有，這么大一個功能需求怎么就被給“河蟹”掉了呢？
另外我覺得還有一個很重要的因素在WASSEC中是被忽略掉的。大家認為安全評估時只在實驗室的調試環境下測試，還是在現網部署的情況下測試下更有效呢？我舉個例子，當年中國移動被黑本身官網的應用程序是沒有任何問題的，但是不代表第三方程序沒有問題啊，更不代表其他虛擬主機沒有問題。那么如何去評估虛擬主機呢？怎么知道有哪些虛擬主機呢？這些現網的情況對開發人員而言都是不可知的。WASS應該提供這些手段。
最后，剩下一個最最重要的問題：該份WASSEC并不具備可操作性。為什么這么說呢？從文檔的內容來看，讀者應當是普通的具有購買傾向的客戶，那么從專業性上來說應當是相對較弱的，畢竟不是專業的安全人士。在這個過程中，如何確認文檔中的內容對于某個廠商的WASS是否滿足呢？舉個實例來說，我們對于WASS對flash文件提取鏈接的能力應當如何去測試呢？甚至能否提取鏈接都是個未知數，難道客戶都得自己先請開發人員做一個flash文件，將不同的鏈接方式加入進去？這樣的可能性基本為零了。到目前為止，沒有任何一個廠商或組織發布一份可以用于滿足WASSEC中提到所有屬性的測試環境。又或者說，該份文檔根本就是一個煙霧，只是為了后面出現一個可供具體操作的環境或者第三方測評機構。當然一個不爭的事實是，文檔的成員廠商是可以堂而皇之的對外宣稱他們是完全支持WASSEC標準的，而其他某某某不是。
與國外相比較而言，國內的安全研究人員更利益驅使一點（短視？），很少有人進行大趨勢或者技術上的一些總結輸出，并且也很少有人體現出“板凳甘坐10年冷”的氣魄。這就就是為什么myspace的蠕蟲和twitter的蠕蟲在國外非常成型且穩定，而國內到目前為止沒有一個實際廣為人知的社區蠕蟲。這肯定不是技術問題，國內在Web安全方面的牛人非常多，技術也很扎實，我甚至覺得國內在Web安全技術方面的研究是超越國外的（我們不否認有國家政策的因素在里面）。我們可以回過頭來看看早在05年，美國一個高中生寫的MySpace蠕蟲的相關技術細節：http://namb.la/popular/tech.html。國內的安全人士是否在敬佩之余也稍微有點汗顏呢？不過話又說回來，國內的這種形勢也是好的，技術還掌握在自己手上不是，只是稍微有些遺憾的是，集大成者還是太少。
如今是個科技化的時代，軍事戰爭一部分已經轉化為信息化戰爭。咱們國人也應當多總結多輸出。咱們稍微細心一點，是能夠發現在WASSEC中帶有排他性的，要說排誰，大家只要減去貢獻者清單所在的廠商就能得出來。咱們的綠盟啊，啟明啊，安恒啊，諾賽啊啥時候也能在某個月黑風高之夜一起討論得出一個基線標準出來，更適合本土化一點，更專業化一點。畢竟安全類產品國家還是得掂量掂量著引進，這個責任你們不承擔誰承擔？
總之，未來的Web應用安全有一段高峰期快來了，不管是WASS也好，WAF也好都會迎來一個高速增長期，希望國內的一些安全廠商能夠爭氣一把，抓緊時機，爭取出現許多個安全界的百年企業。
【編輯推薦】
