摘要
本文主要分为四个部分，一、首先对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应用防护的有效手段。