本文主要分为四个部分，
一、WAF的简单介绍，让读者对WAF这类产品有一个大概了解；
二、通过实例演示如何利用WAF为其后端的Web应用提供安全防护功能；
三、讨论WAF的安全性，介绍一些主流的WAF绕过技术，并结合真实案例演示如何尝试绕过WAF的防护，成功攻击其后端的Web应用；
四、对WAF的安全性进行总结，告诉读者如何用正确、理性的眼光去看待WAF这类产品。
WAF介绍
WAF（Web Application Firewall），中文名称叫做“Web应用防火墙”，利用国际上公认的一种说法，WAF的定义是这样的：Web应用防火墙是通过执行一系列针对 HTTP/HTTPS的安全策略来专门为Web应用提供保护的一款产品。通过从上面对WAF的定义中，我们可以很清晰地了解到：WAF是一种工作在应用层 的、通过特定的安全策略来专门为Web应用提供安全防护的产品。
根据不同的分类方法，WAF可分为许多种。从产品形态上来划分，WAF主要分为以下三大类：
硬件设备类
目 前的安全市场上，大多数的WAF都属于此类。它们以一个独立的硬件设备的形态存在，支持以多种方式（如透明桥接模式、旁路模式、反向代理等）部署到网络中 为后端的Web应用提供安全防护。相对于软件产品类的WAF，这类产品的优点是性能好、功能全面、支持多种模式部署方式等，但它的价格通常比较贵。国内的 绿盟、安恒、启明星辰等厂商生产的WAF都属于此类。
软件产品类
这种类型的WAF采用纯软件的方式实现，特点是安装简单、容易使用、成本低，但它的缺点也是显而易见的——因为它必须安装在Web应用服务器上，除了性能受到限制外，还可能会存在兼容性、安全等问题。这类WAF的代表有ModSecurity、Naxsi、网站安全狗等。
基于云的WAF
随着云计算技术的快速发展，使得其于云的WAF的实现成为了可能，国内创新工场旗下的安全宝和360的网站宝等是这类WAF的典型代表。它的优点是快速部署、零维护、成本低，这对于中、小型的企业和个人站长是很有吸引力的。
利用WAF为Web应用提供防护
在 这里，我们以Naxsi为例来演示下如何利用WAF来为其后端的Web应用提供安全防护。Naxsi是一个开放源代码、高效、低维护规则的Nginx web应用防火墙模块，Naxsi的主要目标是帮助人们加固他们的web应用程序，以抵御SQL注入、跨站脚本、跨域伪造请求、本地和远程文件包含漏洞 等，详见http://code.google.com/p/naxsi/wiki/TableOfContents?tm=6，这里因为篇幅关系就不再 详细的介绍了。本文主要演示Naxsi的安装、配置及防护效果。
部署架构
1将Nginx配置为反向代理；让访问后端Web服务器的流量都经过Nginx
2让Nasxi（WAF）检测经过Nginx的流量，将攻击流量根据相关配置进行阻断，从而保护运行在后端Web服务器上的应用程序。
用户正常访问请求处理流程具体如下图1所示：
图1
攻击者恶意请求处理流程具体如下图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，并测试，如图3所示：
/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所示的错误，
图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
配置过程
这个具体配置分为两个过程：一、修改Nginx.conf配置文件，配置与Naxsi（WAF）相关选项；二、将Nginx配置为反向代理，为后端Web服务器提供防护。
配置Naxsi相关
首先，将Naxsi的核心配置规则库拷贝一份至Nginx文件所在目录，如图5：
图5
接着修改Nginx.conf配置文件，在其中加入如下一行配置，让其包含Naxsi的核心规则库文件，如图6：
图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>
配置反向代理
新建一个虚拟主机的配置文件，具体配置如下图7所示：
图7
最后，再次修改Nginx.conf，使其包含刚定义的虚拟主机配置文件即可，如图8。
图8
重启Nginx服务后配置生效。
防护效果演示
未使用WAF时，不具备攻击防护能力，如图9、图10和图11。
图9
图10
图11
使用WAF后，恶意攻击被阻断，如图12、图13和图14。
图12
图13
图14
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。
图16
3.通过图16，我们可以看到该请求并没有被WAF拦截，而是返回了Web应用的正常页面，说明我们成功绕过了WAF。但是，到此为至，我们仅仅是确认了该Web应用存在SQL注入漏洞。那么，下面我们来尝试构造SQL语句来提取该Web应用数据库的相关信息，结果如图17。
图17
4.通过上面的测试，我们可以确认，将GET请求转换为POST后，可以成功绕过WAF的检测，从而成功获取到目标Web应用的相关信息和数据。此外，其他的WAF也可能会存在同样的问题。
总结
通过上面的介绍和相应的实例演示，相信大家对WAF都有了一个比较全面的认识。那么我们应该如何看待WAF这类产品呢？有两种极端的认识都是错误的，1、部署WAF后，就可以高枕无忧，不用再担心安全问题了；2.WAF没有用，理由是因为其可能会被绕过。
为什么说这两种认识都是错误的呢？首先对于第 一点，WAF作为一种安全产品，防护的是通用型的攻击，通常担任一个虚拟补丁的角色。还有各个厂家的WAF因为实现原理、技术能力、型号等其他方面的原 因，在性能、防护能力上也并不相同，不可一概而论。WAF可以防御大部分的常规攻击，阻挡很大一部分的攻击者，这一点不可否认，否则WAF也就没有存在的 价值。但对于一些技术能力较强的攻击者，WAF并不能阻挡住他们攻击的脚步，他们有能力绕过WAF来成功实施攻击。对于第二点，安全是相对的，世界上没有 哪款安全产品可以提供100%的安全防护。所以笔者对于WAF的态度是，没有必要神化WAF，它并不像厂商说的那样神奇，但也不用过分看淡WAF，毕竟 WAF可以阻挡大部分的常规攻击，可以极大提高Web应用的安全性，是一种Web应用防护的有效手段
转自：http://www.rising.com.cn/newsletter/news/2013-06-27/13976.html
黑客是怎么绕过waf的
前言
今年CNCERT年会上面seay大牛的PPT，详细的分析了WAF的现状，WAF处理数据包的原理和过程以及WAF绕过方法。
WAF的现状：
1.太多数WAF能够拦截较为普通的WEB攻击
2.大多数WAF没有针对热点漏洞奇葩攻击EXP防御的能力
3.基本所有的WAF都存在策略性绕过
4.由于waf的业务限制等各种原因导致存在通用绕过
WAF绕过方法总结：
1.WAF逻辑漏洞及白名单阶段的绕过
2.WAF数据包解析阶段的绕过(通用型绕过)
3.WAF规则策略阶段的绕过
PPT下载
web应用防火墙(WAF)的安全原理与技术分析
防止网页被篡改是被动的，能阻断入侵行为才是主动型的，前边提到的IPS/UTM等产品是安全通用的网关，也有专门针对Web的硬件安全网关，国内 的如：绿盟的Web防火墙，启明的WIPS(web IPS)，国外的有imperva的WAF(Web Application Firewall)等。
Web防火墙，主要是对Web特有入侵方式的加强防护，如DDOS防护、SQL注入、XML注入、XSS等。由于是应用层而非网络层的入侵，从技术 角度都应该称为Web IPS，而不是Web防火墙。这里之所以叫做Web防火墙，是因为大家比较好理解，业界流行的称呼而已。由于重点是防SQL注入，也有人称为SQL防火 墙。
Web防火墙产品部署在Web服务器的前面，串行接入，不仅在硬件性能上要求高，而且不能影响Web服务，所以HA功能、Bypass功能都是必须的，而且还要与负载均衡、Web Cache等Web服务器前的常见的产品协调部署。
Web防火墙的主要技术的对入侵的检测能力，尤其是对Web服务入侵的检测，不同的厂家技术差别很大，不能以厂家特征库大小来衡量，主要的还是看测试效果，从厂家技术特点来说，有下面几种方式：
◆代理服务：代理方式本身就是一种安全网关，基于会话的双向代理，中断了用户与服务器的直接连接，适用于各种加密协议，这也是Web的Cache应 用中最常用的技术。代理方式防止了入侵者的直接进入，对DDOS攻击可以抑制，对非预料的“特别”行为也有所抑制。Netcontinuum(梭子鱼)公 司的WAF就是这种技术的代表。
◆特征识别：识别出入侵者是防护他的前提。特征就是攻击者的“指纹”，如缓冲区溢出时的Shellcode，SQL注入中常见的“真表达 (1=1)”…应用信息没有“标准”，但每个软件、行为都有自己的特有属性，病毒与蠕虫的识别就采用此方式，麻烦的就是每种攻击都自己的特征，数量比较庞 大，多了也容易相象，误报的可能性也大。虽然目前恶意代码的特征指数型地增长，安全界声言要淘汰此项技术，但目前应用层的识别还没有特别好的方式。
◆算法识别：特征识别有缺点，人们在寻求新的方式。对攻击类型进行归类，相同类的特征进行模式化，不再是单个特征的比较，算法识别有些类似模式识 别，但对攻击方式依赖性很强，如SQL注入、DDOS、XSS等都开发了相应的识别算法。算法识别是进行语义理解，而不是靠“长相”识别。
◆模式匹配：是IDS中“古老”的技术，把攻击行为归纳成一定模式，匹配后能确定是入侵行为，当然模式的定义有很深的学问，各厂家都隐秘为“专利”。协议模式是其中简单的，是按标准协议的规程来定义模式;行为模式就复杂一些，
Web防火墙最大的挑战是识别率，这并不是一个容易测量的指标，因为漏网进去的入侵者，并非都大肆张扬，比如给网页挂马，你很难察觉进来的是那一个，不知道当然也无法统计。对于已知的攻击方式，可以谈识别率;对未知的攻击方式，你也只好等他自己“跳”出来才知道。
“自学习”功能的发展：
Imperva公司的WAF产品在提供入侵防护的同时，还提供了另外一个安全防护技术，就是对Web应用网页的自动学习功能，由于不同的网站不可能 一样，所以网站自身页面的特性没有办法提前定义，所以imperva采用设备自动预学习方式，从而总结出本网站的页面的特点。具体的做法是这样的：
通过一段时间的用户访问，WAF记录了常用网页的访问模式，如一个网页中有几个输入点，输入的是什么类型的内容，通常情况的长度是多少…学习完毕 后，定义出一个网页的正常使用模式，当今后有用户突破了这个模式，如一般的帐号输入不应该有特殊字符，而XML注入时需要有“<”之类的语言标 记，WAF就会根据你预先定义的方式预警或阻断;再如密码长度一般不超过20位，在SQL注入时加入代码会很长，同样突破了网页访问的模式。
网页自学习技术，从Web服务自身的业务特定角度入手，不符合我的常规就是异常的，也是入侵检测技术的一种，比起单纯的Web防火墙来，不仅给入侵者“下通缉令”，而且建立进入自家的内部“规矩”，这一种双向的控制，显然比单向的要好。
Citrix公司收购了Teros后，推出的应用防火墙通过分析双向流量来学习Web服务的用户行为模式，建立了若干用户行为模型，一但匹配上你是 某个行为，就按该模式行为去衡量你的行为做法，有“越轨”企图立即给予阻断。这个自适应学习引擎与Imperva公司的网页自学习有些类似，不过一个重点 是学习网页特点，一个是学习用户访问的规律。
从安全角度来说，网业自学习技术与入侵防护结合使用，是理想的选择。
Web防火墙的未来出路：
有一种说法：因为Web服务器前的负载均衡设备、Web 加速设备是不可缺少的，又是Web服务器群的出口必经之路，所以Web防火墙的功能有可能与这些设备合并。这种发展趋势有些象网关UTM与单独的FW、 IPS、AV、VPN等设备进化发展一样，UTM就是这些网关的集合产品。
但我有一个不同的看法：UTM部署于网络的外连接出口，一般是互联网出口，其网络安全隔离作用，这里的带宽价格昂贵，所以拥有大带宽的用户很有限， 而Web服务器群是与网络主交换机连接的，提供的是应用处理能力，要求的参数常是并发用户的数量与在线用户的数量，服务器一般都是千兆接口，目前的交换机 就可达到几十个TB的交换能力，在大流量链路上做多功能的安全产品，又是应用层的检测，对产品的硬件压力是巨大的，能达到“线性”流量的产品一定价格昂 贵，因此Web防火墙的这种合并思路是有待商榷的。
【编辑推荐】
转载请注明：jinglingshu的博客 » WAF攻防实战