打造前后端结合的WAF（应用层防火墙）

前言

之前介绍了一些前后端结合的中间人攻击方案。由于 Web 程序的特殊性，前端脚本的参与能大幅弥补后端的不足，从而达到传统难以实现的效果。
攻防本为一体，既然能用于攻击，类似的思路同样也可用于防御。如果将前端技术结合到传统的WAF中，又能有如何的改进？

机器人的威胁

简单易用，是 Web 服务最大的优势。然而，这也是个致命的弱点。
这种格式简单、标准一致的特征，使得攻击者能利用现有的安全工具，进行大规模、通用化的探测和入侵。甚至无需了解其中的原理。
试想一下，如果某个网站使用私有的二进制协议，那么即使存在漏洞，也得先考虑通信问题。若是寄托于现成的安全工具，那就更举步维艰了。然而现实中是不存在的。通用性和低成本，始终是首要因素。
要模仿这种简单的协议易如反掌。于是，各种需要重复劳动的地方，都能见到机器人的身影。对于需要反复测试的安全领域，更是必不可缺。

传统 WAF

传统 WAF 大多关注于信息监控，记录拦截各种异常的输入输出。对于用户的真假鉴别，并非是其重点。
然而现实中，大多异常的请求，都不是正常用户发起的。有谁会那么闲，把各种帐号一次又一次输入测试撞库？或者反反复复的在浏览器里尝试内网探测？没有工具的协助，安全检测将是无比的折磨。
遗憾的是，WAF 很难从表面上识别用户的真假，只能对其一视同仁。通过之后更详细的规则进行综合分析，才能做出判定。因此，这样的决策似乎有些『有理无据』。
有理。例如正常用户每秒只有几个请求，但攻击者开了漏洞扫描工具，短时间内产生了上百请求，这显然不符合常理。
无据。虽然判定一个用户并不难，但要拿出确凿的证据，却不容易。
这种模糊的规则难免会有一些的误差。若是内网里有人对网站进行入侵探测，很可能导致正常用户也被屏蔽；或者攻击者放慢扫描速度，兴许又能躲过监视。

当然，一套好的规则和模型能让拦截更精准，不过这需要大量的分析和积累。对于 Web 这类特殊群体，我们能否另辟蹊径，寻找一种既简单又靠谱的方案？
在之前讲解的流量劫持系列中也曾提到，后端分析是十分被动的。好在它掌控着流量大权，而 Web 这种特殊流量，同时具备可执行能力。因此可化守为攻，开辟一条全新的作战方案。
所以，我们得借助前端技术，来实现最终目标 —— 做一个有理有据的规则系统。
但一个令人信服的证据不会无中生有，必须人为约定和创造，并在适当的时候将其带上，做到真正的『理据服』。

现有解决方案

在开始构思的我们的『前后端 WAF』之前，有必要提一下现有的解决方案。
每当遇到这种禁止改包重放的场合，安全工程师们总能不假思索的给出解决方案。例如让页面产生个唯一的随机数和时间戳，加密后让后端去验证。
如果仅仅是为了解决个例，这样倒也无可厚非。然而现实中，这样的需求并不少见。如果要让每个业务都去现实这样的方案，将会极大增加前后端开发维护成本。
所以，把一些具体的方案抛给开发者，是很不合理的。**对于开发者来说，理应投入全部精力在产品业务的开发上；与其不相关的事，都应交给适配层，让开发者无需了解任何细节，自动帮其实现。 **
于是，我们需要一个前后端相辅相成的切面系统，在其中透明解决这些琐碎的问题。这样才可大规模部署，以及后期统一更新和维护。

前后端结合 WAF

提到切面，Web『中间件』自然是我们的切入点。和过去的『中间人』劫持类似，我们在页面中注入一段脚本，以开启前端功能。

派出了位于前线的哨兵，就能提供更详细的情报，这在过去是难以实现的。如今前端技术日新月异，利用这些优势，我们开始构思一个全新的系统。
前面提到，如果能在发起请求时，提供一个证据来证明自己不是外人，那样后端就会好办的多 —— 不懂规矩的机器人，自然会立即暴露破绽。
因此我们给页面 IO 做一层切面：在请求发出前一刻，带上一个蕴含各种私密信息的暗号，供后端验证。