WEB攻擊的數(shù)量逐年上升，占了大部分攻擊事件比例。WEB安全已經(jīng)推到了前沿浪尖，無論是政府還是企業(yè)都迫切解決這個棘手的問題，Gartner統(tǒng)計：目前75%攻擊轉(zhuǎn)移到應(yīng)用層。原有的傳統(tǒng)防御設(shè)備已經(jīng)不能滿足企業(yè)對網(wǎng)絡(luò)攻擊的防御。WEB應(yīng)用技術(shù)在積極發(fā)展的同時需要強有力的安全保障，所以WAF是應(yīng)形勢需求誕生的產(chǎn)品，它走上應(yīng)用安全的舞臺，是一個必然的趨勢。

Web漏洞歸類

眾所周知，WEB服務(wù)系統(tǒng)實際不是一個單一的軟件，它由OS+Database+WEB服務(wù)軟件（比如：IIS、Apache）+腳本程序（比如：Jscript、PHP代碼文件）構(gòu)成，所以要考慮它最基本的依賴，那就是OS和Database、WEB服務(wù)軟件自身的安全，這個可以通過安全加固服務(wù)來實現(xiàn)，而最核心的應(yīng)用程序代碼是不能用同樣的手段來解決，這也是WEB安全問題的主要來源。

WEB 應(yīng)用安全漏洞與操作系統(tǒng)或者網(wǎng)絡(luò)設(shè)備的漏洞是不同的，這是因為編寫代碼者是不同的，產(chǎn)生的代碼也是不同的，所以國外有成立正門的WEB安全組織來歸類一些漏洞，讓開發(fā)人員、安全廠家、第三方專家等能用一種一致的語言來討論WEB安全問題。比較有名的是OWASP的TOP10漏洞，還有Web Application Security Consortium (WASC)歸類的Thread Classification，如下表：

從安全角度看，WEB從設(shè)計到開發(fā)必須遵循：

1.安全設(shè)計

2.安全編碼

3.安全測試（代碼審計和掃描、滲透）

4.安全運維

其中最根本的在于安全設(shè)計和安全編碼，也就是上線前必須保證WEB產(chǎn)品的自身強壯性。目前大部分的WEB應(yīng)用程序是用戶自己或請人編寫，其他的或網(wǎng)站里部分組件，比如論壇、郵件系統(tǒng)、留言板等會用到商業(yè)版，代碼是不相同的，而且程序員的水平參差不齊，更重要的是他們都遵循了軟件的安全開發(fā)標(biāo)準(zhǔn)嗎？

記住，這是我們?yōu)槭裁葱枰猈AF的第一個理由！

攻擊從未停止

讓我們先看下圖，是攻擊網(wǎng)站的基本步驟和方法。

如上所示，互聯(lián)網(wǎng)每天都充斥著數(shù)千萬的攻擊流量，而WAF可以自動識別和屏蔽大部分主流的攻擊工具特征，使得它們在攻擊的前奏就失效，綠盟科技WAF采用的是透明代理模式，使得客戶端和服務(wù)器的雙向流量都必須經(jīng)過WAF清洗，而又無需另外配置，保持原有的網(wǎng)絡(luò)結(jié)構(gòu)，每個報文需要接受WAF對其的“搜身檢查”，合格之后再進行轉(zhuǎn)發(fā)。

可能有人會說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)然，作為互補型的IDS（入侵檢測系統(tǒng)）、IPS（入侵防護系統(tǒng)）產(chǎn)品是能防護應(yīng)用層的攻擊行為，但是市面上絕大多數(shù)的產(chǎn)品都只能防護一部分WEB攻擊，甚至有些產(chǎn)品也是直接在IDS類產(chǎn)品上做修改而形成的WAF，基本只依靠規(guī)則來實現(xiàn)，嚴(yán)重滯后于繁雜多樣的WEB攻擊手段。當(dāng)然，我在這里要重申一下，WAF可以和傳統(tǒng)的FS+IPS作為一個有益的補充，但絕不是去代替他們。

所以，WAF的自身代理架構(gòu)使得分析和阻擋攻擊具有天然的優(yōu)勢，這是我們?yōu)槭裁葱枰猈AF的第二個理由！

WAF的防護原理

好，我們再回到防護盲點的產(chǎn)生這個焦點話題，那就是無論如何安全設(shè)計和編碼，或者經(jīng)過最嚴(yán)謹(jǐn)代碼審計、滲透測試之后都難免會有漏洞，因為理論上1000行代碼就有1個Bug，檢查只能讓這些減少而已，無法真正做到?jīng)]有安全漏洞的產(chǎn)品，這也就是為什么軟件廠商會不斷地推出一個個補丁來彌補，而這些Bug只要能被攻擊者發(fā)現(xiàn)和利用那么就會帶來威脅。

也就是說代碼缺陷是先天存在的，即使后來修復(fù)也會具有一定的滯后性，而且不能保證100%地發(fā)現(xiàn)所有存在的漏洞那個缺陷。為了給大家更好地理解WAF防護的天然優(yōu)勢我們從兩個例子來進行分析，從技術(shù)實現(xiàn)角度看WAF，SQL注入采用了規(guī)則集靜態(tài)防護，CSRF采用了算法的動態(tài)防護。#p#

靜態(tài)防護SQL注入

SQL注入的防護一直是焦點話題，從編程角度看最有效的防護是對用戶輸入的變量通過參數(shù)來傳遞，而不是直接嵌入到SQL語句，但缺陷：

1.不是所有的數(shù)據(jù)庫和編程語言都有相應(yīng)的參數(shù)化功能；

2.編寫時面對眾多的輸入模塊，難免會有疏漏；

3.難以批量化和統(tǒng)一部署。

還有一些方法就是把參數(shù)進行分類，比如用戶遞交的參數(shù)值統(tǒng)一轉(zhuǎn)換成純數(shù)字或純字符串類型、加密用戶輸入、限制輸入長度等，但和以上方法的缺陷一樣。

比如這段代碼是直接把用戶輸入放置數(shù)據(jù)庫的SQL語句中進行執(zhí)行，如果不對member_login變量進行過濾和判斷是可以注入攻擊的：

---漏洞代碼段---
member_login=trim(request("login"))
set rs=server.createobject("ADODB.Recordset")
sql="select * from job_Member where Member_login='"&member_login&"'"
rs.open sql,conn,1,3

如果一一檢查和修復(fù)需要花費大量的精力，而很多網(wǎng)站上線運營之后需要提高安全性的普遍舉措是采用一些編寫好的通用性的函數(shù)，原理是對輸入進行判斷和過濾，它在一定程度上能緩解攻擊行為，并且花費成本相對不大，我們先看一段編寫的防護函數(shù)：

---防護代碼段---
<%

'定義需要過濾的輸入字符

dim sql_injdata
SQL_injdata = "'|and|exec|insert|select|delete
|update|count|*|%|chr|mid|master|truncate|char
|declare|1=1|1=2|;"
SQL_inj = split(SQL_Injdata,"|"

'處理POST提交的輸入

If Request.QueryString<>"" Then
For Each SQL_Get In Request.QueryString
For SQL_Data=0 To Ubound(SQL_inj)
if instr(Request.QueryString(SQL_Get),
Sql_Inj(Sql_DATA))>0 Then
Response.Write ""
Response.end
end if
next
Next
End If

'處理GET提交的輸入

If Request.Form<>"" Then
For Each Sql_Post In Request.Form
For SQL_Data=0 To Ubound(SQL_inj)
if instr(Request.Form(Sql_Post),Sql_Inj(Sql_DATA))>0 Then
Response.Write ""
Response.end
end if
next
next
end if
%><%
'定義需要過濾的輸入字符
dim sql_injdata
SQL_injdata = "'|and|exec|insert|select|delete
|update|count|*|%|chr|mid|master|truncate|char
|declare|1=1|1=2|;"
SQL_inj = split(SQL_Injdata,"|"
'處理POST提交的輸入
If Request.QueryString<>"" Then
For Each SQL_Get In Request.QueryString
For SQL_Data=0 To Ubound(SQL_inj)
if instr(Request.QueryString(SQL_Get),
Sql_Inj(Sql_DATA))>0 Then
Response.Write ""
Response.end
end if
next
Next
End If
'處理GET提交的輸入
If Request.Form<>"" Then
For Each Sql_Post In Request.Form
For SQL_Data=0 To Ubound(SQL_inj)
if instr(Request.Form(Sql_Post),Sql_Inj(Sql_DATA))>0 Then
Response.Write ""
Response.end
end if
next
next
end if
%>

以上代碼首先需要定義相對完整的過濾字符集，然后分別處理用GET和POST方式提交的數(shù)據(jù)報文，在需要防護的頁面里調(diào)用包括它既可[an error occurred while processing this directive]

但是編寫統(tǒng)一的防止注入函數(shù)有缺陷：

1.需要考慮不同語言的不同語法，不能統(tǒng)一，比如ASP、PHP、Java；

2.要充分考慮每一個可能用戶輸入的地方，但往往會有疏漏；

3.虛擬機往往有大量站點，而管理者是單個站點的屬主，系統(tǒng)管理員沒權(quán)利也沒能力統(tǒng)一定制防護措施；

4.如果是IDC或者大型企業(yè)的機房，會有更大量不同類型的WEB應(yīng)用服務(wù)器，要實現(xiàn)批量防護則更困難；

5.消耗服務(wù)器運算資源和網(wǎng)絡(luò)帶寬，因為大批量的網(wǎng)絡(luò)連接和提交數(shù)據(jù)都需要經(jīng)過函數(shù)來處理；

6.過濾不嚴(yán)謹(jǐn)則容易被攻擊者繞過。

最后一點其實很關(guān)鍵，不僅僅是過濾不嚴(yán)謹(jǐn)，而且攻擊者對于輸入可變化大小寫，拼接攻擊語句，甚至構(gòu)造字符的不同編碼方式，比如字符 < 可被編碼為 <、<、&#x3c 或 %3c，而編碼方式又是如此之多，Unicode、十六進制、ASIIC、UTF-8等，所以用防護函數(shù)方式是非常困難的。

通過上面描述，我們知道了從編程方式來防御攻擊具有它的局限性，簡單概括：會有疏漏、消耗性能、難以統(tǒng)一、運算復(fù)雜等。

而這時WAF的優(yōu)點就體現(xiàn)出來了，綠盟科技WAF內(nèi)置了50多條精心配制的規(guī)則，用于防護SQL注入，有人可能會疑問這么少的規(guī)則能有效防御嗎？要知道雖然SQL注入的語句千變?nèi)f化，但規(guī)則只需要找出共同點進行匹配即可，并且可在此基礎(chǔ)上自定義規(guī)則。規(guī)則制定后可用于WAF后需要保護的不同類型的多臺WEB服務(wù)器，類型一致的可使用同一規(guī)則，對于大型WEB群來說這具有無可比擬的優(yōu)越性。它的優(yōu)點如下：

1.統(tǒng)一定制的規(guī)則能批量適用于不同類型的網(wǎng)站；

2.花費時間和精力最少，無論是應(yīng)用或編輯規(guī)則都方便，不用每臺WEB服務(wù)器去部署；

3.即使網(wǎng)站存在漏洞，也能在前端把攻擊流量給予清洗和阻斷；

4.網(wǎng)站無需處理錯誤的探測，避免把錯誤處理方式和信息暴露給攻擊者，同時也節(jié)省了服務(wù)器的處理資源。#p#

動態(tài)防護CSRF

CSRF全稱是Cross Site Request Forgery，翻譯過來是跨站請求偽造的意思，它攻擊的是客戶端，利用用戶合法身份訪問精心編制的一串url去觸發(fā)一段具有某功能的腳本或CGI程序，攻擊者盜用了客戶的身份，并以他的名義發(fā)送惡意請求，包括：以假冒身份發(fā)送郵件，發(fā)消息，盜取用戶賬號，購買商品，虛擬貨幣轉(zhuǎn)賬，造成個人隱私泄露以及財產(chǎn)安全。特別是隨著WEB2.0的普及人們越來越意識到它的攻擊威力。如下是一段攻擊流程：

1.訪問了www.example.org

2.此頁面用標(biāo)簽隱含了一段url，但訪問時被觸發(fā)訪問請求

3.這段url以Get方式提交了一段具有某功能執(zhí)行的請求，比如：銀行轉(zhuǎn)賬、網(wǎng)上購物等

通過上圖我們清晰地了解CSRF的攻擊方式是利用合法用戶的身份來執(zhí)行惡意動作，當(dāng)然利用Get方式更容易實施，但POST方式也難逃厄運，比如下一段：

合法鏈接？

如果把鏈接改成圖片，并且動作設(shè)定為onmouseover就更危險了。

目前在WEB服務(wù)端抑制CSRF攻擊有幾種方式：

1.增加一個HASH后的cookie；

2.一次性令牌；

3.加入驗證碼機制，缺點是這種機制給正常用戶的客戶體驗受損。

以上方式第3種是最佳的，比如每次請求重要功能的頁面時（轉(zhuǎn)賬、刪除等動作）會嵌入一個生成驗證碼圖片的腳本，隨機生成值（數(shù)字、ASIIC字符、中文等）讓用戶填寫后發(fā)送到服務(wù)器并保存在session空間。但很多網(wǎng)站的程序員在編寫時疏忽了完成每一次會話后去及時清空這個值，那么用戶只要成功登陸過一次并填寫了驗證碼之后，以后的會話就無需重新驗證了，所以還是容易被利用攻擊。

接著，我們來看看WAF的實現(xiàn)方式，相對于用特征集的靜態(tài)防護，用動態(tài)防護CSRF的攻擊更具職能性和靈活性，基本思路是通過WAF隨機產(chǎn)生的隱含表單來打斷一個不變的會話，也就是說即使攻擊者獲取到了用戶身份，但是隨機變化的驗證碼讓攻擊者無法構(gòu)造一個不變的報文。

如下圖所示，在配置WAF防護的規(guī)則之前需要設(shè)置referee的規(guī)則，然后配置域名和要防護的頁面路徑即可生效。

在應(yīng)用了WAF的csrf防護規(guī)則之后我們可以通過抓包觀察（見下圖），在POST報文時發(fā)現(xiàn)會多了一個隨機生成的隱含表單值，這個值會發(fā)送到WAF中進行匹配計算，如果不想符合則認(rèn)為是攻擊者構(gòu)造的報文。由于這個值每次會話都變化，且長度都不同，很難被攻擊者猜測到利用，具有相當(dāng)高的安全性。

結(jié)束

從以上介紹，我們了解WAF對于繁雜多樣的攻擊能條理地歸類出共性，并在WEB系統(tǒng)前端直接分析和過濾，由于篇幅限制，不能一一列舉WAF所有防護功能的實現(xiàn)原理，其他的包括比如防御CC、SYN_flood等類型的拒絕服務(wù)攻擊、網(wǎng)頁掛馬、防止頁面篡改、WEB訪問加速等，不再詳述。

【編輯推薦】

1. 專家支招：企業(yè)如何發(fā)現(xiàn)自身Web安全漏洞
2. MD5哈希漏洞成為高危Web安全漏洞