许多企业将Web应用程序防火墙(WAF)默认为保护Web应用程序时的优秀实践或合规性要求。WAF是一种特定的防火墙，旨在识别和阻止Web应用程序流量的攻击。期望防火墙将阻止命令注入攻击、跨站点脚本攻击、协议违规以及其他针对Web应用程序的常见攻击。
随着企业数字转型和“安全上云”运动的开展，以及当下疫情加重的Web安全焦虑，越来越多的企业开始考虑云WAF防火墙产品，使用在云中预配置的WAF对Web应用进行保护。除了专业WAF厂商外，目前主要的云供应商都通过收购或者研发丰富了自己的WAF产品，它们与服务商自己的负载均衡器很好地集成在一起。
与传统硬件WAF相比，除了巨大的价格优势外，云WAF还有以下突出优点：
部署简单，维护成本低
这也是云WAF最有价值和受用户喜爱的一点，无需安装任何软件或者部署任何硬件设备，只需修改DNS即可将网站部署到云WAF的防护范围之内。
用户无需更新
云WAF的防护规则都处于云端，新漏洞爆发时，由云端负责规则的更新和维护，用户无需担心因为疏忽导致受到新型的漏洞攻击。
可充当CDN
云WAF在提供防护功能的同时，还同时具有CDN的功能，在进行防护的同时还可以提高网站访问的速率，CDN通过跨运营商的多线智能解析调度将静态资源动态负载到全国的云节点，用户访问某个资源时会被引导至最近的云端节点从而提高访问速度。
但是，目前国际市场上一些有代表性的云WAF产品(本文主要讨论云计算服务商提供的云WAF)，到底“能不能打”?
在Gartner的调研报告下面，很多企业安全人员的留言对云WAF也是褒贬不一，一位软件工程师认为AWS Web Application Firewall是“最可靠的软件”。但另一位专家称云WAF有“需要进一步解决的问题”。至于Azure，评论似乎更加复杂。一位架构师认为，“仍准备了专用WAF设备作为备份”，尽管许多人认为它“易于实施和使用”。
由于目前市场上很少有第三方机构对云计算服务商的云WAF产品进行实战检测，因此客户对云WAF性能和功能的认知，有时候可能只是一种对云安全的“蜜汁自信”。云WAF是否可以很好地阻止常见的Web应用程序攻击?
近日，网络安全团队Fraktal针对AWS WAF (Amazon)、AWS WAF (Fortinet)、AZURE WAF (CRS 3.1)、BARRACUDA(梭子鱼)WAF-as-a-service四款常见的云服务商的云WAF产品(服务)做了一个实战测试，结果有些令人吃惊。测试内容如下：
测试设置
我们在AWS和Azure中搭建了测试环境，以测试云WAF。我们的设置包括以下内容：
- 攻击者的主机在特定的目标Web主机上执行数千个脚本化的测试用例。我们将有效负载注入了发往目标主机的HTTP GET和POST请求。
- 在云容器平台上，目标Web主机运行容器化自定义Web服务器——AWS Elastic Container Service ECS或Azure容器实例ACI。该Web服务器对所有传入HTTP请求反馈HTTP响应代码“200 OK”。
- 目标Web主机前置一个具备WAF功能的云负载平衡器——AWS Elastic Load Balancer ELB或Azure Web Application Gateway。
- 从Azure Marketplace配置的梭子鱼WAF即服务(WaaS)，将流量定向到Azure ACI上的目标Web主机。
测试团队为AWS和Azure内部解决方案挑选了云托管版本的商业WAF产品进行对比测试。四款产品采用的规则/服务如下：
- Azure应用程序网关WAF，使用来自开放式Web应用程序安全项目(OWASP)的CRS 3.1规则
- 使用梭子鱼托管规则从Azure市场配置的梭子鱼WAF即服务(WaaS)
- 使用Amazon托管规则的AWS WAF
- 使用Fortinet托管规则的AWS WAF
在Azure云中，总体测试体系结构如下所示，在AWS云上的测试环境采用了完全相同的设置。
用于测试连接到Azure和AWS云负载平衡器的WAF的高级测试体系结构
测试梭子鱼WAF即服务需要采用备用设置，测试团队在Azure云上配置了服务，对前述设置进行了最小的更改。
用于在Azure中测试梭子鱼WAF即服务的高级体系结构
测试团队使用2月19日当日上述云服务上可用的托管默认值进行了测试。为了准确模拟用户使用这些服务的最常见方式，测试者没有删除或添加任何可能影响检测或阻止攻击能力的规则或定义。对于AWS托管规则，用户必须选择规则组，因为可以同时启用的规则组数量受到限制，测试者选择了一种可以最好地覆盖OWASP十大威胁的规则组合，为测试用例提供最佳保护。
所选规则组
- AWS-AWSManagedRulesSQLiRuleSet
- AWS-AWSManagedRulesLinuxRuleSet
- AWS-AWSManagedRulesKnownBadInputsRuleSet
- AWS-AWSManagedRulesCommonRuleSet
- AWS-AWSManagedRulesPHPRuleSet
- AWS-AWSManagedRulesAdminProtectionRuleSet
测试用例
为了测试WAF，测试团队挑选了几种现实中常见的几种攻击和绕过方法，针对自定义Web服务器通过HTTP发起这些攻击，目标服务器将记录那些通过WAF的请求。
测试使用的攻击方法如下(词条解释引用自owasp.org)：
- 命令执行：通过向应用程序中注入命令破坏系统。
- 服务器端包含注入(SSI)：SSI是Web应用程序上存在的指令，用于向HTML页面提供动态内容。服务器端包含攻击允许通过将脚本注入HTML页面或远程执行任意代码来利用Web应用程序。
- SQL注入：向客户端到应用程序的输入数据中注入SQL查询。
- 路径遍历：路径遍历攻击(也称为目录遍历)旨在访问存储在Web根文件夹外部的文件和目录。
- 格式错误的XML文档：格式错误的文档可用于消耗资源或注入恶意命令。
- 跨站点脚本(XSS)：跨站点脚本(XSS)攻击是一种注入攻击，其中，恶意脚本通过网络浏览器从恶意网站注入到原本良性和可信任的网站中。
这组测试方法代表了针对网站的典型攻击。测试用例的目的不涉及业务逻辑弱点，以及其他可被恶意利用的应用逻辑。
检测结果
结果是令人震惊的，除了Azure WAF，其他几款云WAF的表现都是灾难性的。
四大云WAF测试结果数据(百分比表示被阻止的攻击比重，数字越高越好)
肉眼可见，使用CRS 3.1规则的Azure WAF的攻击防护成功率远高于其他三款云WAF产品，也是在整个测试用例集中能可靠执行的唯一云WAF服务。
测试报告的另外一个有趣发现是，是否使用URL字符编码，对WAF的安全性能表现影响极大!例如，梭子鱼阻止了我们所有未编码的SSI测试用例，但在编码时则仅能阻止一半。因此，从攻击者的角度来看，尝试使用不同的编码可能是逃避WAF保护的有效方法。
几个小事实
AWS托管的WAF在本次测试中的表现最为“宽松”，它会放行以下有效载荷进行攻击：
此外，AWS中托管的Fortinet WAF和Azure中的梭子鱼WAF即服务也都允许这两个示例。
从有效载荷和拒绝的响应来看，很难对WAF的内部运作得出许多结论。有时，WAF的各种行为看上去非常混乱和搞笑，例如：
- AWS托管WAF对POST和GET请求的处理方式似乎完全不同。例如这个请求在GET请求中被阻止，但在POST请求中被允许：%2e%2e//etc/passwd。
- AWS托管WAF能够阻止有效负载ls-l/var/www/*，但却又允许有效负载&& ls-l/var/www/*，|ls-l/var/www/*依此类推。
- 梭子鱼WAF即服务在该字符'是有效载荷的唯一字符时会坚定地阻止该字符，但同时又允许这样的有效载荷，例如eval('sleep 5');和'whoami。
结论
结果表明，云WAF服务生下来就是不平等的，而且大多数IaaS云服务商的WAF服务还远远赶不上第三方方案。接受测试的AWS、Azure和梭子鱼中，Azure WAF无疑是赢家，并且是唯一运行良好的服务。而AWS和梭子鱼的产品，对一些最常见的攻击类型都“睁一只眼闭一只眼”。
如果企业要在云中构建应用程序，则应留意“选配”的安全服务是否能够达到安全需求。虽然购买云WAF可能是一种合规需要，但用户应当清醒地认识到，云计算厂商的“免费午餐”，有时候安全性能可能与您想象得不太一样。
声明
本项云WAF测试由Fraktal网络安全团队的Tuomo、Tommi和Marko完成，其测试结果仅基于特定测试环境和配置，除了在特定测试环境和用例中比较云WAF服务的相对性能之外，这些测试结果无意在任何其他上下文应用场景中进行解释或作为用户选择产品的依据。
【本文是51CTO专栏作者“安全牛”的原创文章，转载请通过安全牛（微信公众号id:gooann-sectv）获取授权】
