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

Web漏洞歸類

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

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

從安全角度看，WEB從設計到開發必須遵循：

1.安全設計

2.安全編碼

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

4.安全運維

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

記住，這是我們為什么需要WAF的第一個理由！

攻擊從未停止

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

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

可能有人會說Firewall和IPS不是這樣的設備嗎？它們為什么不能防御呢？詳細的對比參數我就不列舉了，大家知道OSI 7層模型，防火墻通常工作在OSI的第三層，也就是針對網絡層，包括包過濾型和狀態包檢測型防火墻，即使是應用層防火墻也無法阻擋大多數WEB攻擊行為，這是它自身技術定位決定的局限性。攻擊者只需在瀏覽器上操縱URL就可攻擊目標網站。當然，作為互補型的IDS（入侵檢測系統）、IPS（入侵防護系統）產品是能防護應用層的攻擊行為，但是市面上絕大多數的產品都只能防護一部分WEB攻擊，甚至有些產品也是直接在IDS類產品上做修改而形成的WAF，基本只依靠規則來實現，嚴重滯后于繁雜多樣的WEB攻擊手段。當然，我在這里要重申一下，WAF可以和傳統的FS+IPS作為一個有益的補充，但絕不是去代替他們。

所以，WAF的自身代理架構使得分析和阻擋攻擊具有天然的優勢，這是我們為什么需要WAF的第二個理由！

WAF的防護原理

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

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

靜態防護SQL注入

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

1.不是所有的數據庫和編程語言都有相應的參數化功能；

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

3.難以批量化和統一部署。

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

比如這段代碼是直接把用戶輸入放置數據庫的SQL語句中進行執行，如果不對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

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

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

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

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方式提交的數據報文，在需要防護的頁面里調用包括它既可[an error occurred while processing this directive]

但是編寫統一的防止注入函數有缺陷：

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

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

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

4.如果是IDC或者大型企業的機房，會有更大量不同類型的WEB應用服務器，要實現批量防護則更困難；

5.消耗服務器運算資源和網絡帶寬，因為大批量的網絡連接和提交數據都需要經過函數來處理；

6.過濾不嚴謹則容易被攻擊者繞過。

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

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

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

1.統一定制的規則能批量適用于不同類型的網站；

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

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

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

動態防護CSRF

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

1.訪問了www.example.org

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

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

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

合法鏈接？

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

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

1.增加一個HASH后的cookie；

2.一次性令牌；

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

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

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

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

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

結束

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

【編輯推薦】

1. 專家支招：企業如何發現自身Web安全漏洞
2. MD5哈希漏洞成為高危Web安全漏洞