--------------------- 轉摘於 http://www.secsky.cn/216.html
摘要
本文主要分爲四個部分，一、首先對WAF做了簡單的介紹，讓讀者對WAF這類產品有一個大概的瞭解；二、這部分通過一個實例演示瞭如何利用WAF爲其後端的Web應用提供安全防護功能；三、安全是相對的，世界上任何一款安全產品都不可能提供100%的安全防護功能，WAF也是一樣。因此，第三部分主要討論了WAF的安全性，介紹了一些主流的WAF繞過技術，並結合真實案例來演示瞭如何嘗試繞過WAF的防護，成功***其後端的Web應用；四、這部分對WAF的安全性進行了總結，告訴讀者如何用正確、理性的眼光去看待WAF這類產品。
1、WAF介紹
WAF（Web Application Firewall）的中文名稱叫做“Web應用防火牆”，利用國際上公認的一種說法，WAF的定義是這樣的：Web應用防火牆是通過執行一系列針對HTTP/HTTPS的安全策略來專門爲Web應用提供保護的一款產品。通過從上面對WAF的定義中，我們可以很清晰的瞭解到，WAF是一種工作在應用層的、通過特定的安全策略來專門爲Web應用提供安全防護的產品。
根據不同的分類方法，WAF可分爲許多種。從產品形態上來劃分，WAF主要分爲以下三大類：
1.1硬件設備類
目前安全市場上，大多數的WAF都屬於此類。它們以一個獨立的硬件設備的形態存在，支持以多種方式（如透明橋接模式、旁路模式、反向代理等）部署到網絡中爲後端的Web應用提供安全防護。相對於軟件產品類的WAF，這類產品的優點是性能好、功能全面、支持多種模式部署等，但它的價格通常比較貴。國內的綠盟、安恆、啓明星辰等廠商生產的WAF都屬於此類。
1.2軟件產品類
這種類型的WAF採用純軟件的方式實現，特點是安裝簡單，容易使用，成本低。但它的缺點也是顯而易見的，因爲它必須安裝在Web應用服務器上，除了性能受到限制外，還可能會存在兼容性、安全等問題。這類WAF的代表有ModSecurity、Naxsi、網站安全狗等。
1.3基於雲的WAF
隨着雲計算技術的快速發展，使得其於雲的WAF實現成爲可能。國內創新工場旗下的安全寶、360的網站寶是這類WAF的典型代表。它的優點是快速部署、零維護、成本低。對於中、小型的企業和個人站長是很有吸引力的。
2、利用WAF爲Web應用提供防護
在這裏，我們以Naxsi爲例來演示下如何利用WAF來爲其後端的Web應用提供安全防護。Naxsi是一個開放源代碼、高效、低維護規則的Nginx web應用防火牆模塊。Naxsi的主要目標是幫助人們加固他們的web應用程序，以抵禦SQL注入、跨站腳本、跨域僞造請求、本地和遠程文件包含漏洞。詳見http://code.google.com/p/naxsi/wiki/TableOfContents?tm=6
，這裏因爲篇幅關係就不再詳細的介紹了，這裏主要演示Naxsi的安裝、配置及防護效果。
2.1部署架構：
2.1.1將Nginx配置爲反向代理；讓訪問後端Web服務器的流量都經過Nginx
2.1.2讓Nasxi（WAF）檢測經過Nginx的流量，將***流量根據相關配置進行阻斷，從而保護運行在後端Web服務器上的應用程序。
用戶正常訪問請求處理流程具體如下圖所示：
圖1
***者惡意請求處理流程具體如下圖：
圖2
2.2 Nginx+Naxsi安裝
安裝包：
Nginx 1.3.15：http://nginx.org/download/nginx-1.3.15.tar.gz
Naxsi 0.50：http://naxsi.googlecode.com/files/naxsi-core-0.50.tgz
pcre-8.32：http://sourceforge.net/projects/pcre/files/pcre/8.32/pcre-8.32.tar.gz/download
安裝過程：
安裝必要的支持組件
在安裝Nginx之前，需要先安裝必要的支持組件，否則Nginx無法正常安裝。
安裝pcre過程：
[root@localhost LNMP]# wget http://sourceforge.net/projects/pcre/files/pcre/8.32/pcre-8.32.tar.gz/download
[root@localhost LNMP]#tar -zxvf pcre-8.32.tar.gz
[root@localhost nginx-1.3.15]#cd pcre-8.32
[root@localhost pcre-8.32]]#./configure
[root@localhost pcre-8.32]#make && make install
安裝zlib庫組件過程：
[root@localhost LNMP]# yum -y install zlib-devel
Nginx和Naxsi安裝過程
[root@localhost LNMP]# wget http://nginx.org/download/nginx-1.3.15.tar.gz
[root@localhost LNMP]# wget http://naxsi.googlecode.com/files/naxsi-core-0.50.tgz
[root@localhost LNMP]# tar -zxvf nginx-1.3.15.tar.gz
[root@localhost LNMP]# tar -zxvf naxsi-core-0.50.tgz
[root@localhost LNMP]# cd nginx-1.3.15
[root@localhost nginx-1.3.15]# ./configure --add-module=../naxsi-core-0.50/naxsi_src
[root@localhost nginx-1.3.15]#make && make install
啓動Nginx，並測試
/usr/local/nginx/sbin/nginx #啓動Nginx
/usr/local/nginx/sbin/nginx -t #測試配置文件是否正常
Killall -9 nginx #殺死nginx進程
kill -HUP `cat /usr/local/www/nginx/logs/nginx.pid` #以平滑方式重啓Nginx
圖3
如果在啓動Nginx時，出現如下錯誤：
圖4
按照下面的方法即可解決。
32位系統 [root@localhost lib]# ln -s /usr/local/lib/libpcre.so.1 /lib
64位系統 [root@localhost lib]# ln -s /usr/local/lib/libpcre.so.1 /lib64
2.3配置過程：
這個具體配置分爲兩個過程：一、修改Nginx.conf配置文件，配置與Naxsi（WAF）相關選項；二、將Nginx配置爲反向代理，爲後端Web服務器提供防護。
2.3.1配置Naxsi相關
首先，將Naxsi的核心配置規則庫拷貝一份至Nginx文件所在目錄，
圖5
接着修改Nginx.conf配置文件，在其中加入如下一行配置，讓其包含Naxsi的核心規則庫文件：
圖6
然後定義一個虛擬主機的安全規則，可參考下面的內容：
LearningMode; #Enables learning mode
SecRulesEnabled;
#SecRulesDisabled;
DeniedUrl "/RequestDenied";
include "/tmp/naxsi_rules.tmp";
## check rules
CheckRule "$SQL >= 8" BLOCK;
CheckRule "$RFI >= 8" BLOCK;
CheckRule "$TRAVERSAL >= 4" BLOCK;
CheckRule "$EVADE >= 4" BLOCK;
CheckRule "$XSS >= 8" BLOCK;
將上面的內容保存在一個文件中。如test.rules。下面會用到。
自定義一個阻斷頁面，當WAF檢測到***時，會將該頁面返回給用戶，可參考如下內容：
<html>
<head>
<title>Error 403 Request Denied</title>
</head>
<body>
<h2>Error 403 Request Denied</h2>
For some reasons, your request has been denied.
</body>
</html>
2.3.2配置反向代理
新建一個虛擬主機的配置文件，具體配置如下圖所示：
圖7
最後，再次修改Nginx.conf，使其包含剛定義的虛擬主機配置文件即可。
圖8
重啓Nginx服務後配置生效。
2.4防護效果演示
未使用WAF時，不具備***防護能力。
圖9
圖10
圖11
使用WAF後，惡意***被阻斷。
圖12
圖13
圖14
3、WAF安全介紹
WAF作爲一種安全產品爲Web應用提供安全防護，可以增大***者的***難度和***成本，這一點是不容至疑的。但是，WAF並不是萬能的，世界上沒有任何一款安全產品可以提供100%的安全防護。由於產品的設計或實現原理，及其他問題都有可能導致***者可以成功繞過WAF的防護，來達到***後端Web應用的目的。除了WAF自身的安全性以外，現在討論最多的就是WAF的繞過技術。在介紹WAF繞過技術之前，我們必須要要搞明白一個問題，那就是WAF爲什麼會存在被繞過的風險？這是因爲WAF對數據包的解析和Web服務器對數據包的解析兩者之間存在差異，所以存在被繞過的可能。下面列出了一些在SQL注入過程中主流的WAF繞過技術：
1.轉換特徵字符大小寫
2.利用註釋繞過
3.編碼特徵字符繞過
4.分隔重寫特徵字符繞過
5.利用截斷字符繞過
6.變換變量位置繞過
7.針對域名保護的繞近
8.超大數據包繞過
9.轉換數據提交方式繞過
10.HPP（HTTP參數污染）繞過
上面列出的這些WAF繞過技術網上都有相應的詳細介紹，這裏因爲篇幅關係就不再介紹了，感興趣的讀者可以自行百度查找相關資料。下面我們通過一個真實案例來介紹下WAF的繞過。
WAF繞過技術實例
在前段時間安全寶舉辦的一個WAF繞過活動中，白帽子們通過各種技巧成功繞過了安全寶的WAF。下面以一個我發現的WAF繞過技巧來進行說明：
背景介紹：
在一個存在SQL注入漏洞的Web應用前面部署了安全寶的雲WAF，訪問Web應用的流量首先要經過WAF，由WAF檢測是否存在***行爲，如果WAF檢測到惡意***行爲，將向***者返回特定的阻斷頁面。否則，將返回正常的頁面。
1.先通過經典的“and 1=1”去判斷該Web應用是否存在SQL注入漏洞。因爲前端有WAF的防護，正常情況該請求應該會被WAF攔截。同預想的結果一樣，當我們發送有***特徵的請求時，會WAF阻斷，返回了一個405的錯誤頁面。
圖15
2.現在我們嘗試將GET請求轉換爲POST，在POST的請求中帶上***字符串，來判斷是否是被WAF攔截。結果如何呢？請看下圖：
圖16
3.通過上圖我們可以看到該請求並沒有被WAF攔截，而是返回了Web應用的正常頁面。說明我們成功繞過了WAF。但是，到此爲至，我們僅僅是確認了該Web應用存在SQL注入漏洞。那麼下面我們來嘗試構造SQL語句來提取該Web應用數據庫的相關信息。結果如下圖：
圖17
4.通過上面的測試，我們可以確認，將GET請求轉換爲POST後，可以成功繞過WAF的檢測，從而成功獲取到目標Web應用的相關信息和數據。其他的WAF也可能會存在同樣的問題。
4、總結
通過上面的介紹和相應的實例演示，相信讀者對WAF都有了一個比較全面的認識。那麼我們應該如何看待WAF這類產品呢？有兩種極端的認識都是錯誤的，1、部署WAF後，就可以高枕無憂，不用再擔心安全問題了；2.WAF沒有用，理由是可能會被繞過。
爲什麼說這兩種認識都是錯誤的呢？首先對於第一點，WAF作爲一種安全產品，防護的是通用型的***，通常擔任一個虛擬補丁的角色。還有各個廠家的WAF因爲實現原理、技術能力、型號等其他方面的原因在性能、防護能力上也並不相同，不可一概而論。WAF可以防禦大部分的常規***，阻擋很大一部分的***者，這一點不可否認，否則WAF也就沒有存在的價值了。但對於一些技術能力較強的***者，WAF並不能阻擋住他們***的腳步，他們有能力繞過WAF來成功實施***。對於第二點，其實我們前面已經說過了，安全是相對的，世界上沒有哪款安全產品可以提供100%的安全防護。所以，我對於WAF的態度是，沒有必要神化WAF，它並不像廠商說的那樣神奇，但也不用過分看淡WAF，畢竟WAF可以阻擋大部分的常規***，可以極大提高Web應用的安全性，是一種Web應用防護的有效手段。