如何應(yīng)對WEB攻擊的防護(hù)盲點(diǎn)
WEB攻擊的數(shù)量逐年上升，占了大部分攻擊事件比例。WEB安全已經(jīng)推到了前沿浪尖，無論是政府還是企業(yè)都迫切解決這個(gè)棘手的問題，Gartner統(tǒng)計(jì)：目前75%攻擊轉(zhuǎn)移到應(yīng)用層。原有的傳統(tǒng)防御設(shè)備已經(jīng)不能滿足企業(yè)對網(wǎng)絡(luò)攻擊的防御。WEB應(yīng)用技術(shù)在積極發(fā)展的同時(shí)需要強(qiáng)有力的安全保障，所以WAF是應(yīng)形勢需求誕生的產(chǎn)品，它走上應(yīng)用安全的舞臺，是一個(gè)必然的趨勢。
Web漏洞歸類
眾所周知，WEB服務(wù)系統(tǒng)實(shí)際不是一個(gè)單一的軟件，它由OS+Database+WEB服務(wù)軟件（比如：IIS、Apache）+腳本程序（比如：Jscript、PHP代碼文件）構(gòu)成，所以要考慮它最基本的依賴，那就是OS和Database、WEB服務(wù)軟件自身的安全，這個(gè)可以通過安全加固服務(wù)來實(shí)現(xiàn)，而最核心的應(yīng)用程序代碼是不能用同樣的手段來解決，這也是WEB安全問題的主要來源。
WEB 應(yīng)用安全漏洞與操作系統(tǒng)或者網(wǎng)絡(luò)設(shè)備的漏洞是不同的，這是因?yàn)榫帉懘a者是不同的，產(chǎn)生的代碼也是不同的，所以國外有成立正門的WEB安全組織來歸類一些漏洞，讓開發(fā)人員、安全廠家、第三方專家等能用一種一致的語言來討論WEB安全問題。比較有名的是OWASP的TOP10漏洞，還有Web Application Security Consortium (WASC)歸類的Thread Classification，如下表：
從安全角度看，WEB從設(shè)計(jì)到開發(fā)必須遵循：
1.安全設(shè)計(jì)
2.安全編碼
3.安全測試（代碼審計(jì)和掃描、滲透）
4.安全運(yùn)維
其中最根本的在于安全設(shè)計(jì)和安全編碼，也就是上線前必須保證WEB產(chǎn)品的自身強(qiáng)壯性。目前大部分的WEB應(yīng)用程序是用戶自己或請人編寫，其他的或網(wǎng)站里部分組件，比如論壇、郵件系統(tǒng)、留言板等會(huì)用到商業(yè)版，代碼是不相同的，而且程序員的水平參差不齊，更重要的是他們都遵循了軟件的安全開發(fā)標(biāo)準(zhǔn)嗎？
記住，這是我們?yōu)槭裁葱枰猈AF的第一個(gè)理由！
攻擊從未停止
讓我們先看下圖，是攻擊網(wǎng)站的基本步驟和方法。
如上所示，互聯(lián)網(wǎng)每天都充斥著數(shù)千萬的攻擊流量，而WAF可以自動(dòng)識別和屏蔽大部分主流的攻擊工具特征，使得它們在攻擊的前奏就失效，綠盟科技WAF采用的是透明代理模式，使得客戶端和服務(wù)器的雙向流量都必須經(jīng)過WAF清洗，而又無需另外配置，保持原有的網(wǎng)絡(luò)結(jié)構(gòu)，每個(gè)報(bào)文需要接受WAF對其的“搜身檢查”，合格之后再進(jìn)行轉(zhuǎn)發(fā)。
可能有人會(huì)說Firewall和IPS不是這樣的設(shè)備嗎？它們?yōu)槭裁床荒芊烙兀吭敿?xì)的對比參數(shù)我就不列舉了，大家知道OSI 7層模型，防火墻通常工作在OSI的第三層，也就是針對網(wǎng)絡(luò)層，包括包過濾型和狀態(tài)包檢測型防火墻，即使是應(yīng)用層防火墻也無法阻擋大多數(shù)WEB攻擊行為，這是它自身技術(shù)定位決定的局限性。攻擊者只需在瀏覽器上操縱URL就可攻擊目標(biāo)網(wǎng)站。當(dāng)然，作為互補(bǔ)型的IDS（入侵檢測系統(tǒng)）、IPS（入侵防護(hù)系統(tǒng)）產(chǎn)品是能防護(hù)應(yīng)用層的攻擊行為，但是市面上絕大多數(shù)的產(chǎn)品都只能防護(hù)一部分WEB攻擊，甚至有些產(chǎn)品也是直接在IDS類產(chǎn)品上做修改而形成的WAF，基本只依靠規(guī)則來實(shí)現(xiàn)，嚴(yán)重滯后于繁雜多樣的WEB攻擊手段。當(dāng)然，我在這里要重申一下，WAF可以和傳統(tǒng)的FS+IPS作為一個(gè)有益的補(bǔ)充，但絕不是去代替他們。
所以，WAF的自身代理架構(gòu)使得分析和阻擋攻擊具有天然的優(yōu)勢，這是我們?yōu)槭裁葱枰猈AF的第二個(gè)理由！
WAF的防護(hù)原理
好，我們再回到防護(hù)盲點(diǎn)的產(chǎn)生這個(gè)焦點(diǎn)話題，那就是無論如何安全設(shè)計(jì)和編碼，或者經(jīng)過最嚴(yán)謹(jǐn)代碼審計(jì)、滲透測試之后都難免會(huì)有漏洞，因?yàn)槔碚撋?000行代碼就有1個(gè)Bug，檢查只能讓這些減少而已，無法真正做到?jīng)]有安全漏洞的產(chǎn)品，這也就是為什么軟件廠商會(huì)不斷地推出一個(gè)個(gè)補(bǔ)丁來彌補(bǔ)，而這些Bug只要能被攻擊者發(fā)現(xiàn)和利用那么就會(huì)帶來威脅。
也就是說代碼缺陷是先天存在的，即使后來修復(fù)也會(huì)具有一定的滯后性，而且不能保證100%地發(fā)現(xiàn)所有存在的漏洞那個(gè)缺陷。為了給大家更好地理解WAF防護(hù)的天然優(yōu)勢我們從兩個(gè)例子來進(jìn)行分析，從技術(shù)實(shí)現(xiàn)角度看WAF，SQL注入采用了規(guī)則集靜態(tài)防護(hù)，CSRF采用了算法的動(dòng)態(tài)防護(hù)。#p#
靜態(tài)防護(hù)SQL注入
SQL注入的防護(hù)一直是焦點(diǎn)話題，從編程角度看最有效的防護(hù)是對用戶輸入的變量通過參數(shù)來傳遞，而不是直接嵌入到SQL語句，但缺陷：
1.不是所有的數(shù)據(jù)庫和編程語言都有相應(yīng)的參數(shù)化功能；
2.編寫時(shí)面對眾多的輸入模塊，難免會(huì)有疏漏；
3.難以批量化和統(tǒng)一部署。
還有一些方法就是把參數(shù)進(jìn)行分類，比如用戶遞交的參數(shù)值統(tǒng)一轉(zhuǎn)換成純數(shù)字或純字符串類型、加密用戶輸入、限制輸入長度等，但和以上方法的缺陷一樣。
比如這段代碼是直接把用戶輸入放置數(shù)據(jù)庫的SQL語句中進(jìn)行執(zhí)行，如果不對member_login變量進(jìn)行過濾和判斷是可以注入攻擊的：
|
如果一一檢查和修復(fù)需要花費(fèi)大量的精力，而很多網(wǎng)站上線運(yùn)營之后需要提高安全性的普遍舉措是采用一些編寫好的通用性的函數(shù)，原理是對輸入進(jìn)行判斷和過濾，它在一定程度上能緩解攻擊行為，并且花費(fèi)成本相對不大，我們先看一段編寫的防護(hù)函數(shù)：
|
以上代碼首先需要定義相對完整的過濾字符集，然后分別處理用GET和POST方式提交的數(shù)據(jù)報(bào)文，在需要防護(hù)的頁面里調(diào)用包括它既可[an error occurred while processing this directive]
但是編寫統(tǒng)一的防止注入函數(shù)有缺陷：
1.需要考慮不同語言的不同語法，不能統(tǒng)一，比如ASP、PHP、Java；
2.要充分考慮每一個(gè)可能用戶輸入的地方，但往往會(huì)有疏漏；
3.虛擬機(jī)往往有大量站點(diǎn)，而管理者是單個(gè)站點(diǎn)的屬主，系統(tǒng)管理員沒權(quán)利也沒能力統(tǒng)一定制防護(hù)措施；
4.如果是IDC或者大型企業(yè)的機(jī)房，會(huì)有更大量不同類型的WEB應(yīng)用服務(wù)器，要實(shí)現(xiàn)批量防護(hù)則更困難；
5.消耗服務(wù)器運(yùn)算資源和網(wǎng)絡(luò)帶寬，因?yàn)榇笈康木W(wǎng)絡(luò)連接和提交數(shù)據(jù)都需要經(jīng)過函數(shù)來處理；
6.過濾不嚴(yán)謹(jǐn)則容易被攻擊者繞過。
最后一點(diǎn)其實(shí)很關(guān)鍵，不僅僅是過濾不嚴(yán)謹(jǐn)，而且攻擊者對于輸入可變化大小寫，拼接攻擊語句，甚至構(gòu)造字符的不同編碼方式，比如字符 < 可被編碼為 <、<、< 或 %3c，而編碼方式又是如此之多，Unicode、十六進(jìn)制、ASIIC、UTF-8等，所以用防護(hù)函數(shù)方式是非常困難的。
通過上面描述，我們知道了從編程方式來防御攻擊具有它的局限性，簡單概括：會(huì)有疏漏、消耗性能、難以統(tǒng)一、運(yùn)算復(fù)雜等。
而這時(shí)WAF的優(yōu)點(diǎn)就體現(xiàn)出來了，綠盟科技WAF內(nèi)置了50多條精心配制的規(guī)則，用于防護(hù)SQL注入，有人可能會(huì)疑問這么少的規(guī)則能有效防御嗎？要知道雖然SQL注入的語句千變?nèi)f化，但規(guī)則只需要找出共同點(diǎn)進(jìn)行匹配即可，并且可在此基礎(chǔ)上自定義規(guī)則。規(guī)則制定后可用于WAF后需要保護(hù)的不同類型的多臺WEB服務(wù)器，類型一致的可使用同一規(guī)則，對于大型WEB群來說這具有無可比擬的優(yōu)越性。它的優(yōu)點(diǎn)如下：
1.統(tǒng)一定制的規(guī)則能批量適用于不同類型的網(wǎng)站；
2.花費(fèi)時(shí)間和精力最少，無論是應(yīng)用或編輯規(guī)則都方便，不用每臺WEB服務(wù)器去部署；
3.即使網(wǎng)站存在漏洞，也能在前端把攻擊流量給予清洗和阻斷；
4.網(wǎng)站無需處理錯(cuò)誤的探測，避免把錯(cuò)誤處理方式和信息暴露給攻擊者，同時(shí)也節(jié)省了服務(wù)器的處理資源。#p#
動(dòng)態(tài)防護(hù)CSRF
CSRF全稱是Cross Site Request Forgery，翻譯過來是跨站請求偽造的意思，它攻擊的是客戶端，利用用戶合法身份訪問精心編制的一串url去觸發(fā)一段具有某功能的腳本或CGI程序，攻擊者盜用了客戶的身份，并以他的名義發(fā)送惡意請求，包括：以假冒身份發(fā)送郵件，發(fā)消息，盜取用戶賬號，購買商品，虛擬貨幣轉(zhuǎn)賬，造成個(gè)人隱私泄露以及財(cái)產(chǎn)安全。特別是隨著WEB2.0的普及人們越來越意識到它的攻擊威力。如下是一段攻擊流程：
1.訪問了www.example.org
2.此頁面用標(biāo)簽隱含了一段url，但訪問時(shí)被觸發(fā)訪問請求
3.這段url以Get方式提交了一段具有某功能執(zhí)行的請求，比如：銀行轉(zhuǎn)賬、網(wǎng)上購物等
通過上圖我們清晰地了解CSRF的攻擊方式是利用合法用戶的身份來執(zhí)行惡意動(dòng)作，當(dāng)然利用Get方式更容易實(shí)施，但POST方式也難逃厄運(yùn)，比如下一段：
合法鏈接？
如果把鏈接改成圖片，并且動(dòng)作設(shè)定為onmouseover就更危險(xiǎn)了。
目前在WEB服務(wù)端抑制CSRF攻擊有幾種方式：
1.增加一個(gè)HASH后的cookie；
2.一次性令牌；
3.加入驗(yàn)證碼機(jī)制，缺點(diǎn)是這種機(jī)制給正常用戶的客戶體驗(yàn)受損。
以上方式第3種是最佳的，比如每次請求重要功能的頁面時(shí)（轉(zhuǎn)賬、刪除等動(dòng)作）會(huì)嵌入一個(gè)生成驗(yàn)證碼圖片的腳本，隨機(jī)生成值（數(shù)字、ASIIC字符、中文等）讓用戶填寫后發(fā)送到服務(wù)器并保存在session空間。但很多網(wǎng)站的程序員在編寫時(shí)疏忽了完成每一次會(huì)話后去及時(shí)清空這個(gè)值，那么用戶只要成功登陸過一次并填寫了驗(yàn)證碼之后，以后的會(huì)話就無需重新驗(yàn)證了，所以還是容易被利用攻擊。
接著，我們來看看WAF的實(shí)現(xiàn)方式，相對于用特征集的靜態(tài)防護(hù)，用動(dòng)態(tài)防護(hù)CSRF的攻擊更具職能性和靈活性，基本思路是通過WAF隨機(jī)產(chǎn)生的隱含表單來打斷一個(gè)不變的會(huì)話，也就是說即使攻擊者獲取到了用戶身份，但是隨機(jī)變化的驗(yàn)證碼讓攻擊者無法構(gòu)造一個(gè)不變的報(bào)文。
如下圖所示，在配置WAF防護(hù)的規(guī)則之前需要設(shè)置referee的規(guī)則，然后配置域名和要防護(hù)的頁面路徑即可生效。
在應(yīng)用了WAF的csrf防護(hù)規(guī)則之后我們可以通過抓包觀察（見下圖），在POST報(bào)文時(shí)發(fā)現(xiàn)會(huì)多了一個(gè)隨機(jī)生成的隱含表單值，這個(gè)值會(huì)發(fā)送到WAF中進(jìn)行匹配計(jì)算，如果不想符合則認(rèn)為是攻擊者構(gòu)造的報(bào)文。由于這個(gè)值每次會(huì)話都變化，且長度都不同，很難被攻擊者猜測到利用，具有相當(dāng)高的安全性。
結(jié)束
從以上介紹，我們了解WAF對于繁雜多樣的攻擊能條理地歸類出共性，并在WEB系統(tǒng)前端直接分析和過濾，由于篇幅限制，不能一一列舉WAF所有防護(hù)功能的實(shí)現(xiàn)原理，其他的包括比如防御CC、SYN_flood等類型的拒絕服務(wù)攻擊、網(wǎng)頁掛馬、防止頁面篡改、WEB訪問加速等，不再詳述。
【編輯推薦】
