Web Application Firewall （WAF）是 AWS 的一个新特性，它部署在用户公开网站的前端，保护网站免受异常流量的侵扰。WAF 的工作机制类似于反向代理，对传入的 HTTP 请求进行检查，查找其中活动可疑的模式。正常的请求才会被传递给用户的 Web 应用做处理，而异常的请求则会被阻塞。WAF 是一种无需更改现有应用即可为应用添加一层安全的工具。
通过设置一些用于识别并管理可疑流量的策略，我们可以配置 WAF 的行为。Amazon 已发布了 PDF 格式的白皮书，阐述了如何使用 WAF 去规避在 Web 应用中最广为出现的“ OWASP 十大安全漏洞”。对于所请求的传入请求（例如安全令牌），或是受限的传入请求（例如 SQL 关键字），不少推荐方法使用字符串匹配去检查请求的头部或主体内容。为实现更多的威胁检测，还有一些方法建议将 WAF 与 Lambda 或 CloudFront 组合。
WAF 是一种通用工具，它对于部分类型的攻击的成功率，要远高于其它类型的攻击。通过分析请求，相对易于规避注入攻击，这无需知道应用的上下文。用户可以配置 WAF 去检查请求查询字符串中的 SQL 关键字，实现对可疑活动的阻止。但是对于那些借助于颠覆应用上下文内安全的攻击，则是难以规避的。如果用户应用使用了独特的跨站请求伪造（Cross-Site Request Forgery，CSRF）令牌，我们无法配置 WAF 去拒绝一个重放已用令牌的请求，这需要在 WAF 和用户应用间构建一个用户定制的集成。
就 WAF 这类通用工具是否可以成功地加固那些不安全的 Web 应用这一问题，InfoQ 采访了 Mark Nunnikhoven 。Mark 是 Trend Micro 云技术研究部门的副总，也是一位 AWS 社区英雄（Community Hero）。
InfoQ：你认为近期高调出现的一些违规行为是否能被 WAF 这样的工具所阻止？
Mark Nunnikhoven：违规行为的发生是有一系列的原因，但常见的是利用 Web 应用的漏洞。跨站脚本攻击 (Cross Site Scripting) 和 SQL 注入攻击持续是被攻击者所采用的一些特别有效的方法。AWS WAF 对这些攻击方法非常有效。WAF 在设计上就是分析 Web 应用流量并查找异常，它对于用户的 Web 应用是一种简单并有效的防御层。
InfoQ：“OWASP 的十大安全漏洞”是很多安全规划、审计和 WAF 等工具的关注点。是否能解决这十大安全漏洞就足矣？或者为了加固 Web 应用，还需要考虑更多的问题？
Nunnikhoven：“OWASP 的十大安全漏洞”近期做了一些更新，但令人沮丧的是改动并不大。开发人员继续在犯着同样的错误，平台也继续在暴露类似的问题。安全问题具有长尾效应，十大安全漏洞只是给出一些最大的关注点。如果一个应用能很好地解决这十个领域问题，那么该应用就具有着坚实的安全基础。如果用户还没有率先解决这些基础的问题，那么完全没有必要去操心那些不太可能会影响到自身应用及用户的未知攻击。
InfoQ：我们可以使用 WAF 的工作流为模型创建自己定制的代理，在不改变应用的情况下增加安全。这是否有可能？或者还是需要通过修改应用才能解决安全缺陷？
Nunnikhoven：任何第三方的安全控制都是设计用于强化应用，AWS WAF 也是如此。安全控制是一种安全的网络，那些破坏了良好设计的应用及其支撑平台的问题会落在网中，并被安全网络所捕获。
InfoQ：安全正成为云的一个特性。AWS 提供了 WAF 和 Amazon Inspector 特性，后者检查部署中的不安全配置。Azure 提供了 Security Center 特性，自动规避安全攻击，并给出增加安全的推荐。安全是否能构成了迁移到云端的一个正当理由？
Nunnikhoven：安全绝对是迁移到云的一个理由。各大云服务提供商，例如提供全球范围服务的 AWS、Microsoft 和 Google，提供了强大的基础服务，用户可以在此上构建自己的应用，这些应用都运行于共享责任模型下。这就是用户和云服务提供商间在六个主要领域（即物理、架构、虚拟化、操作系统、应用和数据）上划分日常职责之处。
这一模型意味着用户可聚焦于更少的领域。用户将部分工作代理给服务提供商，仅需验证所提供的服务是否适合自身的需求。使用云技术，我们可以花用很少的精力完成很多的事情。这对于构建安全应用是一个非常好的环境。
查看英文原文： AWS Web Application Firewall: Bolt-on Security for Insecure Websites
评论