Web安全性問題的層次關系分析

　　大家經常會聽到看到很多很多有關安全性方面的信息，可以說形形色色，對於在網絡安全方面不太專業的同志來說，有點眼花缭亂，理不出頭緒。在這裡，我來幫大家整理一下。

　　以我個人多年來從事Web安全方面的工作經驗及國外一些權威安全機構對Web安全的層次性的理解，我們通常把它分為三個層次：

　　1、網絡安全。如防火牆、路由器、網絡結構等相關的安全問題；

　　2、系統與服務安全。如Window/Linux/Unix系統本身的漏洞或運行於其上的服務的安全，象Apache/OpenSSL/Weblogic等本身的安全性漏洞；

　　3、Web應用程序安全。具體應用程序的安全性漏洞，比如：某網站郵件系統因為存在腳本安全性問題，導致該郵件系統的用戶在收到具有惡意代碼的郵件時不知不覺的，其密碼與帳號信息被人竊取。

　　說到這，大家應該清楚，不管你是在任何地方看到有關計算機安全性問題的方方面面，都逃不出這三大部分，同時我也要向讀者聲明一下：在這裡，我主要是給大家陸續的介紹上述第三部分內容，即Web應用程序安全性相關知識與技能。

　　據權威搜索引擎公司統計數據顯示，目前70%以上的網站，或多或少的存在安全隱患，這裡的安全隱患指的就是Web應用程序的安全。至於網絡、系統與服務的安全性問題，我個人認為它的生存周期基本上是：發現->上報軟件開發商->打補丁->下載更新程序。作為我們用戶，及時的給系統與服務打上最新的補丁，配合一定的防火牆安全策略，是可以基本保證其安全的。但是Web應用程序基本上是每個組織各持一套自己的程序，一切問題都必需自己動手去解決，恰恰因為此種特性，才導致目前運行於互聯網上的Web應用的安全性普遍存在。為什麼呢？

　　因為只有少數組織或個人有能力駕馭網絡安全相關的技術與經驗，而絕大多數的即使是專業做網站開發的公司也不一定有知識有能力或有意識去考慮安全性問題。還要向讀者羅嗦一點是的：安全需要意識，沒有安全意識的組織與個人，是無法保證其開發出的產品的安全性的。這一點很重要，很多人只是從媒體上看到聽到一些安全性問題，總覺得安全性問題離自己很遙遠，其不知安全性問題正在對其造成越來越嚴重的破壞……。

　　前不久上海有一位朋友，銀行卡的資金不明轉出，且被人取走，報警後，經警方多方調查跟蹤，最絡查明：其經常使用網上銀行的筆記本電腦中了“灰鴿子木馬，導致其操作電腦的行為及其電腦上的現在資源完全暴露無遺。有人要問：“灰鴿子是如何跑到其計算機上的呢？當然進去的途徑有多種，比如我們是網友，我通過QQ發給你讓你運行一下；或者我向你推薦一款你比較感興趣的免費軟件，該軟件內部已經綁定了“灰鴿子木馬程序……，還有一點很重要的就是通過網頁來傳播。比如通過腳本注入的方式，強行的不停的提示你下載並運行該程序；通過上傳漏洞上傳到一個你信任的網站上，當它提示你下載並安裝時，你發現它來自你信任的網站，於是就接受了……

　　總之，Web應用程序是我們接觸最多最有可能通過帶來安全隱患的載體。

　　相信大家都或多或少的聽過關於各種Web應用安全漏洞，諸如：跨site腳本攻擊(XSS)，SQL注入，上傳漏洞……形形色色。

　　在這裡我並不否認各種命名與歸類方式，也不評價其命名的合理性與否，我想告訴大家的是，形形色色的安全漏洞中，其實所蘊含安全問題本質往往只有幾個。 我個人把Web應用程序安全性本質問題歸結以下三個部分：

　　1、輸入/輸出驗證(Input/output validation)

　　2、角色驗證或認證(Role authentication )

　　3、所有權驗證(Ownership authentication)

　　說到這，讀者一定想知道我這三種分類與形形色色的安全性問題有什麼關系？下面我逐個給您概略解答：

　　輸入/輸出驗證

　　這裡的輸入與輸出其實都是發生在用戶界面（User Interface）這一個層面上的，比如：你某一站點上提交一份注冊信息，往往會收到諸多提示：“用戶名非法，“姓名不能使用英文“……其實這就是輸入驗證的一個實例。什麼情況是輸出呢？比如說你成功提交一份注冊信息後，系統會返回一個確認頁（Registerred Confirmation），往往在這個頁面上會顯示你注冊時提交的部分或全部信息，那麼在這裡顯示的信息就是我所說的輸出實例之一，輸入需要做什麼驗證？

　　假如你在提交時，在Address那一欄輸入：

　　 《script》alert("iwebsecurity");《/script》

　　當你到達注冊的確認頁時，會有什麼發生？如果確認頁沒有做輸出驗證處理，那很顯然會在到達確認頁的時候出現一個Javascript打出的提示框。其實這就是跨site腳本攻擊的一個小小的實例。當然了，單純的輸入／輸出驗證涉及的面可能夠寫一小本書了，努力在後續文章中給大家詳解。

　　角色驗證或認證

　　我們就拿CSDN來說吧，用戶有這些角色：其一可以說是游客，就是浏覽者沒有登錄時的角色；其二是免費的注冊用戶；或許將來CSDN深入發展了，業務有所更新，還會出現收費的注冊用戶。以上只是用戶角色，那在CSDN公司內部還會有管理員角色，還有可能管理員又可以根據板塊分為各種不同的角色。大家看到了吧，你天天訪問的CSDN一共可能有多少角色？接下來的問題就是權限問題了，為什麼會有角色？就是為了控制權限的。每種角色都有自己特定的與公共的權限，這些權限的邏輯關系是相當復雜的，如果一個Web應用在角色上沒有一個詳細的合理的設計，將會給開發人員帶來無限痛苦和麻煩。那現在我要問幾個問題：你能保證每種角色只能做其份內的事兒？你是如何去保證的呢？方法可靠嗎？有沒有漏洞？……這，就是我要說的角色驗證或認證。BTW：為什麼我會說驗證或認證呢？你可以這麼理解，角色性存在於兩個階段，其一進入階段，比如你登錄的那一瞬間，你進入了一個特定的角色；另一個階段就是維持階段，你如何確保你登錄後總是以登錄時的身份在操作呢？那前者可以說是：認證，後者就是驗證了。

　　給一個角色認證／驗證方面的虛擬案例，比如：一個在線電影服務提供商，會免費給您開一個試用角色，如果這試用角色驗證不當，可能會導致用戶權限提升而成為一個合法的收費用戶，而這個收費用戶你往往卻收不到他的任何費用。

　　所有權驗證

　　這個問題的存在也是基於角色的，只不過它所關心的是同級別的角色之間的權限問題。就拿CSDN來說吧，我是CSDN的一個免費用戶，你也是。

　　現在的問題是：我可以替你操作嗎，我可以替你發表文章嗎？我能修改你的個性設置嗎？如果不能，CSDN是如何實現的？雖然你和我都是普通用戶，但是你有你的隱私我也有我的隱私，如何保證嚴格的所有權驗證就顯得尤為關鍵了。比較簡單吧，這就是我所說的所有權驗證。

　　我可以很自信的告訴你，只要是Web應用安全性問題，它逃不出在這三大部分，可能你還無法把形形色色的Web應用安全性問題與這三個部分對應並合理的解釋清楚，但是確實只有這麼簡單的幾個部分。