提到防火墙，大家的思想可能还停留在诸如入侵检测防火墙之类的拦截过滤IP包以及网络攻击流量上面。
的确，此类防火墙在过去的很多年中应用非常广泛，目前也仍然被频繁部署到企业级网络环境以及个人应用环境中。但随着Web应用的爆炸式成长，此类IDS设备对于应用层尤其是HTTP应用层就显得越来越力不从心了。
2008年，大规模SQL自动注入让Web安全越来越被人们所关注，Web应用防火墙也就应运而生。顾名思义，Web应用防火墙（Web Application Firewall，下面简称WAF）是专注于Web应用层上的应用级防火墙。
利用WAF可以有效地阻止各类针对Web应用的攻击，比如SQL注入、XSS攻击等。表1列出了2007年OWASP组织统计出的十大Web应用漏洞。
表1 2007年十大Web应用漏洞
| A1 - Cross Site Scripting (XSS) | XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute script in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc. |
| A2 - Injection Flaws | Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data. |
| A3 - Malicious File Execution | Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise. Malicious file execution attacks affect PHP, XML and any framework which accepts filenames or files from users. |
| A4 - Insecure Direct Object Reference | A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization. |
| A5 - Cross Site Request Forgery (CSRF) | A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks. |
| A6 - Information Leakage and Improper Error Handling | Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks. |
| A7 - Broken Authentication and Session Management | Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities. |
| A8 - Insecure Cryptographic Storage | Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud. |
| A9 - Insecure Communications | Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications. |
| A10 - Failure to Restrict URL Access | Frequently, an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly. |
同时，国际的WAF评估标准也分别在如下几个方面对于WAF应该满足的标准作了定义和指导。
1. HTTP协议支持度方面（包含HTML支持度）。
2. 检测技术方面。
·标准/主动/被动检测
·安全规则库
·可扩展APIs
3. 保护技术方面。
·暴力攻击抵御
·Cookie安全保护
·Session攻击抵御
·隐藏表单区域保护
·URL以及参数保护
·Request保护
4. 日志 （应当有完备的360度日志功能）。
5. 报告。
6. 管理与维护。
7. 性能指标。
·HTTP层级上的性能表现
·HTTPS层级上的性能表现
·在生产环境下的负载性能表现
这里我们先谈谈WAF的Web应用保护的几种模式，后面几篇随笔中依次探讨其他内容。现在国际大厂的WAF（比如F5以及Citrix等厂商）一般采用如下两种过滤模式。
1. 基于一定检测理论的特征码模式。
2. 基于主动学习的主动防御模式。
国内的Windows平台WAF基本上都是由IIS Filter来实现，或者直接基于Apache ModSecurity（可以做独立反向代理服务器）。WAF从其部署上来看，可以有多找那个模式，比如可以内嵌于Web Server中（IIS ISAPI或者Apache模块）也可以做反向代理或者作为路由模式。国内目前的WAF其设计模式基本上全部基于第一种模式，也就是基于特征码检测的机制，比如开源的WebKnight 、Snort等。
先从第一种模式谈起，这种模式的检测机制是依靠不断更新的特征码来抵御各类Web攻击，类似于目前的杀毒软件病毒库，其风险是一旦有新型变形关键字，就可以轻易绕过此类Web应用防火墙的检测。
而且这类基于关键字检测识别的防御模式（第一种模式），在很多情况下只是简单的关键字查找，正则表达式匹配等这类非常初级的特征码检测技术手段，基本上都没有去基于某种完备的特征码识别理论，纯粹依靠开发者的个人功底来实现这部分的特征码检测核心模块。那么这部分WAF其实是非常简陋的，包括WebKnight在内，很多WAF都存在同样的问题。Port80Software的ServerDefender也是同样的检测机制，只是它基于一定的检测理论支持，而非简单的字符串识别这么简单的匹配规则。Snort相对比较成熟，在特征码检测匹配方面采用了改进的BM算法。
第一种模式并非完美，但是也是必不可少的，只是需要基于某些成熟的特征码检测识别理论，其安全性才会大大加强。
第二种模式则各家实现各不相同，但本质上是一样的，就是允许在生产部署之前，通过手动或者自动学习模式来完成其安全检测知识库的构建。从这一点来看，比较类似于语音识别软件。语音识别软件首先会让用户朗读各种典型应用的文字段落，从中不断学习和识别关键语音片段。WAF的主动防御模式就是基于此基础来实现。
WAF主动防御模式有的厂商实现为在生产环境下通过自动学习并将学习知识库即时应用，但是并不建议这种做法.因为对于关键应用而言，一旦出现失误就直接导致关键Web应用被此WAF阻挡，那可就是耽误了大事。
WAF主动防御的自动模式可以在部署前的完整测试环境下开启，以便快速构建主动防御知识库（Active Defense Repository）。
1. 首次上线
WAF主动防御机器人 –> 循环遍历需要保护的Web网站（上线前测试环境下）-> 构建主动防御知识库 –> 人工审核辨别知识库条目，并编辑 –> 测试主动防御知识库 -> 正式部署Web App+WAF到生产环境，并开启主动防御模式。
2. 迭代更新阶段
此阶段的特点是，每次网站程序更新幅度较小，为迭代式增量更新模式。
手动开启WAF机器人 -> 检索新目录或新应用程序站点 -> 构建增量主动防御知识库 ->人工审核确认知识库条目；
或者
直接手动在主动防御知识库中添加需要的知识条目即可。
3. 主动防御知识库管理
管理员可以随时手工管理知识库中的知识条目，并帮助主动防御模块学习更新的知识条目。
之所以不在生产环境下开启WAF框架层的自动学习，也是为了避免知识条目噪声的出现。
有机结合基于成熟理论的特征码检测机制与主动防御检测机制，就可以在最大程度上保证Web应用程序的安全。
当然，治本的话还是需要开发人员从源码级别来做到抵御各类Web攻击才对，不过由于实际情况往往不是预想的那么理想，在越来越多的
场景中需要WAF来加以补充和配合。但接触WAF首先要明确的就是，并不是说有了WAF，开发人员就不必关心Web安全了。
下面一篇探讨如何选择并实现高效的多模式匹配算法来进行特征码检测模块的设计。
最后，有一份读者调查问卷表，还能烦请各位博友能帮忙参与一下，十分感谢！ 一分钟时间。
Web应用防火墙读者调查问卷
http://www.cnblogs.com/turingbooks/archive/2009/07/07/1518493.html