大概十年前，Web应用防火墙（WAF）进入了IT安全领域，最早提供这类产品的供应商是几家新兴公司，如Perfecto（曾改名为Sanctum，后在2004年被WatchFire收购）、KaVaDo（2005年被Protegrity收购）和NetContinuum（2007年被Barracuda收购）。工作原理相当简单：随着攻击范围向IP堆栈的上层移动，瞄上针对特定应用的安全漏洞，这时势必需要开发旨在识别和预防这些攻击的产品。虽然网络防火墙在阻止较低层攻击方面很有效，但并不擅长解开IP数据包层，以分析较高层协议；这就意味着，网络防火墙缺少应用感知功能，而要关闭自定义Web应用中的漏洞窗口，就需要这种功能。
但是尽管WAF炒得很火，供应商承诺的优点也很多，但最终用户的使用体验却相当差。早期产品存在诸多缺点，比如误报率高，给受保护应用的性能带来负面影响，又很难有效地管理。2005年前后，包括思科、思杰和F5在内的大牌网络供应商或收购或开发了Web层监控技术，WAF随之成为一道公认的边界安全防线。促使WAF得到主流用户采用的另一个因素是，出台了支付卡行业数据安全标准（PCI-DSS），该标准在第6.6项需求中明确要求使用具有应用层感知功能的防火墙。
如今，WAF已是IT安全工具箱中一个公认的组成部分。但许多企业仍在为这个问题而纠结：该买哪一种WAF、如何最合理地把它们集成到Web应用风险管理产品系列中。本文分析了采购WAF方面一些主要的决策因素，并给出了相应的建议，以便确保它们很适合企业架构和网络生态系统。
架构和物理尺寸
WAF应该适合于现有的架构，并采用得到安全操作团队接受和支持的物理尺寸。WAF放置方面主要有两种架构方案可以考虑：桥接模式（in-line）或分接/跨接模式（tap/span）。
桥接模式：在这种架构（又叫主动配置）中，WAF就直接放在请求方（如浏览器客户端）与Web应用服务器之间的流量路径当中。WAF在检查应用请求和响应之后再传送请求和响应。
在桥接模式里面，WAN到底采用哪一种方法来传送流量，企业可以作出众多选择。网络方面的选择有：路由器（3层）、网桥（2层）和HTTP反向代理系统。WAF还可以直接在主机服务器（Web应用驻留在上面）上使用，这种WAF名为基于主机的WAF或嵌入式WAF。使用网桥模式的WAF可能不需要改动网络，但流量必须定向至路由器或反向代理模式中的WAF。
要选择一种最佳模式，先要评估一下目前网络上的Web应用是如何构建的：该应用是不是已经在反向代理系统的后面？如果是这样，企业又想继续使用反向代理架构，可以考虑支持这种需要的WAF。如果企业要求WAF终结SSL连接，以检查数据包内容，那么反向代理系统是个理想的选择。不过，在一路发送数据包内容之前终结连接（无论是不是SSL连接）的确需要处理能力，所以需要对这种模式进行造型和测试，确保不会带来让人无法接受的延迟。
桥接式WAF经配置后，可以主动阻止违反WAF规则集的请求和流量。这项功能很有用，但使用要慎重——要是桥接式WAF过于主动地阻止，就会阻止合法流量进入到Web服务器，因而导致应用无法使用。在制定任何主动阻止规则之前，先要进行全面测试，确保生产环境中不会出现服务意外受到干扰的情况。另外，可以以桥接方式使用WAF，但要让它处于纯监控（或被动）模式。
架构方面要考虑的另一个因素是，将安装和管理多少个WAF。如果需要WAF用于多个场合，那不妨考虑支持分布式管理或分布式WAF的解决方案。在这种模式下，可使用中央控制台来管理用于多个场合的防火墙。可以针对所有WAF统一运用规则或设置；也可以根据每个WAF的情况，逐个运用规则集，具体取决于WAF在保护哪一种Web应用。
表格1：桥接式WAF的优缺点
分接/跨接模式：这种模式又叫"被动"模式，因为WAF被挡在流量路径外面，从分接端口或跨接端口监控流量。分接/跨接式WAF常常用于收集数据，以便之后用于调查或取证分析。这种架构模式的一个主要优点是，它并不干扰网络流量或吞吐量，因为它不是直接嵌入。而另一方面，不在流量路径当中意味着，这种解决方案无法执行主动的桥接式WAF所能执行的那种阻止操作。不过，支持某些形式的阻止操作，比如连接重置，或者通过联系到另一个系统（如网络防火墙），然后让该系统执行阻止操作。
图2：分接/跨接式WAF的优缺点
新的变化：两个重要变化在促使企业需要WAF使用新的架构模式，这两个变化就是云计算和虚拟化。基于云的WAF先拦截流量，然后允许合法流量进入到企业网络；或者对于在云环境也有Web应用的公司来说，允许合法流量通过云进入到服务器。虚拟化环境带来了一个独特的挑战，因为在虚拟机管理程序上运行的虚拟机构成了自己的小型网络；在这个网络中，流量从一虚拟服务器传送到另一虚拟服务器，没必要通过网络传送。为了防止虚拟机内部出现应用攻击，WAF需要能够查看流量。使用应用编程接口（API）或其他服务，通过虚拟机管理程序来监控活动，就能做到这一点。
物理尺寸：探讨一下WAF如何捆绑和销售给客户的问题。许多WAF支持多种物理尺寸选择，所以企业不需要为购买硬件设备而大伤脑筋，只要独立软件开发商（ISV）的软件得到批准。换句话说，选择什么物理尺寸的硬件取决于贵企业最习惯于什么。选择包括：
纯软件——硬件由采购部门负责提供
设备——软件与专门针对WAF进行选型和调整的设备捆绑销售
硬件——WAF智能直接嵌入在硬件本身里面
主机——这是一种软件方案，但软件安装在运行Web应用的同一台服务器上，而不是安装在单独的主机或虚拟机上。
检测技术
刚才已讨论了架构和物理尺寸问题，现在要问一下这个问题：WAF如何检测Web应用中的漏洞以及针对Web应用的攻击？WAF的目的是智能地保护Web应用，所以拥有细粒度规则和检测机制很要紧。大多数WAF采用结合不同检测技术的方法，确保检测范围最广泛、结果最准确。除了问供应商使用哪些检测技术外，还要让供应商出示证明误报率/漏报率的依据以及第三方测试结果，以便更清楚地了解WAF在实际使用时效果会有多好。下面是一些检测技术，以及向最后选出来的几家产品供应商询问的几个问题：
特征：与为反恶意软件和网络入侵检测系统（IDS）编写的特征很相似，WAF特征也将预定字符串或正则表达式（RegEx）与流量进行匹配，以查找已知攻击。
该产品在交付时随带一套特征吗？
供应商每隔多久更新特征？
规则：规则在特征概念的基础上更进了一步，它可以用逻辑“与”运算符把一系列字符串联系起来，用"或"运算符添加更复杂的匹配机制，或者用“非”运算符实现“排斥”功能。还可以设定规则，寻索非常特定的字符串类型，就像16位号码（比如信用卡号），作为来自Web服务器的响应而发送。一些WAF能够动态“学习”流量模式，根据一套基准规则来查找异常行为。“学到”的信息可以发送给管理员，提议针对WAF或互补性保护设备（如IDS或网络防火墙）设定什么样的新规则。
供应商提供基准规则吗？
客户能够手动添加新规则吗？
WAF能够动态“学习”新规则吗？
规范化：攻击者的一种惯用手法是，对漏洞的有效载荷做手脚，冒充没有危害的内容（比如对有效载荷的一部分进行URL编码），从而避开WAF的检测。为了检测出这种攻击，WAF就要能够对请求进行规范化处理，以便进行分析。以下是仅仅几个规范化机制--完整清单请参阅Web应用安全联盟Web应用防火墙评估标准的第3.1章节。
WAF能够对转义字符或编码字符（如t、01、%2C、xAA和uAABB）进行规范化吗？
使用自引用路径（即使用/./和等效的编码方案）吗？
使用混合大小写和国际字符集吗？
API：如果企业想自行开发自定义检测技术或规则，以便进行特别评估，比如逻辑检查，可以通过API来做到这点。咨询一下供应商，看看对方是否的确支持API；如果支持，这些API与WAF分析引擎的集成又有多紧密？
WAF有API吗？
API与WAF引擎的集成有多紧密？
供应商为自定义插件提供哪一种支持？