WEB安全是一个老生常谈的话题，但是随着互联网向各个行业更加深入的渗透，比如说大家耳熟能详的“互联网金融”，“FIN-TECH”，“互联网+”大数据和AI等相关技术的发展，WEB应用安全逐渐由单纯的WEB安全漏洞的转向了业务安全，从各个维度扩充了原有的WEB安全的范围，笔者希望可以尽量从不同的方面来思考WEB 3.0时代的WEB应用安全，跟大家共同探讨，共同学习。
0x01 WEB应用发展简史
WEB的发展可以简要的概括成一下几个阶段：
1. WEB 1.0的时代：
在WEB 1.0时代，网站的主要内容就是静态的，由文字和图片组成，制作形式也是也表格为主。当时的用户行为也很简单，就是简单的浏览网页，WEB1.0一开始是为大型企业、商业公司服务，将企业的信息搬运到网上，向人们宣传企业。WEB1.0是静态的、单项的网络。大型商业公司通过网络把他们的产品发布到网上，然后人们可以通过网络浏览信息，如果客户有中意的商品，便可以和公司取得联系。此外，第一代WEB用途相当有限，只是简单的信息检索。最典型的网站应该是花花公子的网站了，（题外花絮，花花公子据说还是最早使用负载均衡的网站呢）下图是早期的apple的官网。
在这个时代， WEB的网站开发基本就是HTML、URL和HTTP三个规范，构成了WEB 1.0的核心体系结构，是支撑着WEB运行的基石，整个WEB网站也并没有运行复杂的业务逻辑，所以在这个时代，WEB安全基本就是防止网站被黑。（挂个国旗，刷个标语之类的，你懂的）
2. WEB 2.0的时代
到了2005年以后，互联网进入了WEB2.0时代，各种类似桌面软件的WEB应用大量出现。网站的前端也发生了翻天覆地的变化，网页不再单纯的有图片和文字组成了，因为已经满足不了用户的需求了，网页上的交互也给用户带来了很好的体验，越来越多的业务开始搬迁到互联网。最典型的WEB 2.0的业务就网银和电子商务平台。
在WEB 2.0的环境下，WEB开发的也有了巨大的变化。从WEB编程脚本语言PHP/ASP/JSP的出现到分布式企业计算平台J2EE/.Net，到各种框架横飞的年代：MVC，ORM等，基本大量的业务逻辑都是通过后台来处理，前台的基本还是展现为主。下图是一个典型的MVC开发框架：
WEB 2.0时代由于页面的交互大大增强，并且后台存储采用了大量的数据库来存储各种数据，由于http协议的便利性和后台开发系统的代码薄弱以及大量的后台数据给黑客们带来了巨大的吸引力，在这个阶段，WEB安全的问题大量的爆发。包括各种SQL，XSS攻击，未授权访问等各种WEB攻击层出不穷。
3. WEB 3.0的时代
Web 2.0时代，企业主要是提供尽可能丰富的内容和信息供用户来使用，3.0时代在大数据、AI和物联网等技术的加持下，3.0时代极大的扩充了企业主动向用户推送的内容来进行精准化的营销或者业务拓展，用户和后台业务交互的内容、场景和方式都得到了极大的扩充，由于消费需求的场景会经常发生变化，所以web 3.0时代用户体验和用户的各种个性化需求都会极大的被满足。为了满足用户的个性化需求，海量的各种应用开始出现。同时用户信息成为最有价值的数据，如果没有了用户信息，上面所述的很多功能就无法落地。所以我们经常看到很多初创企业不停的烧钱，就是为了获取用户，更直白的说，就是要获取用户信息，PDD为啥可以那么高估值在海外上市，不就是通过微信群的病毒式营销获取了号称有好几亿用户嘛。
在WEB 3.0时代，WEB应用开发最典型的变化：
1. 前后端的完全分离了。前后端的关键协作点是 WEB service (API) 接口，规定好交互接口后，前后端工程师就可以根据约定，分头开工，开发环境中通过Mock等方式进行测试，同时在特定时间节点进行前后端集成测试。在目前的互联网+的大环境下，客户都提倡业务的敏捷开发和快速迭代的情况下，这种开发模式对加快开发进度是有明显的帮助。同时，现在的企业都非常的注重客户的体验，这种前后端分离的模式，极大的降低的前后端交互时传输的数据量（2.0时代动不动就几百K的页面，现在只有几K大小的JSON字段），页面都是根据后端返回的JSON数据在本地生成，比起以前的由后端生成页面的模式，用户体验得到了极大的提升。但是，随着业务功能的愈发复杂（看看现在的Gmail），这种模式本质上和JSP时代的WEB开发并无本质区别，只不过是将复杂的业务逻辑从JSP文件转移到了JavaScript文件中而已。现在，对于一个前端功能、交互复杂的SPA，JavaScript代码很容易膨胀（超过10万行）。很自然地，像服务端从JSP向MVC框架转换的过程一样，前端开发也出现了大量的MVC框架，比较典型的包括VueJS, AngularJS, EmberJS, KnockoutJS。总的来说，MVC框架的提出是为了解决前端开发的复杂度，提供一套规则组织代码、分层（MVC），通过合理的组织和分层，前端的代码职责明确、清晰，便于开发与测试。
2. 大量的使用各种开源框架。BAT的互联网思想和工具随着大量的ex BATer进入各行各业，各行各业（包括最传统的金融行业）都在大量使用开源产品来加快开发进度以应对来自业务部门的压力。
0x02 黑客攻击思路和工具的变化
随着脚本语言（以python为代表），自动化运维技术和AI技术的兴起，就目前看来，对黑客们的帮助更大，极大的降低了黑客入门的门槛和扩展了黑客攻击的范围和攻击效率。尤其是在现在互联网上存在着海量的已经泄露的数据库信息，黑客完全可以通过各种自动化工具，采用更加轻松和相对安全的方法来获取各种用户信息和数据。
以下是几个典型的使用了自动化技术或AI技术的新型web攻击工具：
1.WAScan：一款功能强大的Web应用程序扫描工具
WAScan是一款开源工具，该工具采用的是基于黑盒的漏洞挖掘方法，这也就意味着研究人员无需对Web应用程序的源代码进行研究，它可以直接被当作成一种模糊测试工具来使用，并且能够对目标Web应用的页面进行扫描，提取页面链接和表单，执行脚本攻击，发送Payload或寻找错误消息等等。
WAScan基于Python 2.7开发，能够跨平台使用。
其功能非常丰富：
注入攻击：
网站URL扫描：
暴力破解：
2. AI打码平台
该类型的工具是打码平台为对抗验证码系统而生。对于“验证码”，大家并不陌生。在登录各网站、平台、APP时，经常见到。常见的“验证码”有“字符式”、“字符+点选式”、“滑块拼图式”和难度逆天的“12306式”。
验证码（CAPTCHA ，Completely Automated Public Turing Test to Tell Computers and Humans Apart，全自动区分计算机和人类的图灵测试），是区分计算机和人类的一种程序算法，简单解释是一个答题的验证。系统向请求发起方提问，能正确回答的即是人类，反之则为机器。从安全角度讲，CAPTCHA经过不断演化，已成为目前国内外各大互联网公司用于对抗网络黑产恶意行为（如恶意登录）的验证码安全策略，即我们现在俗称的验证码系统。
在网络黑产中，不法分子窃取网站数据库后，需要确认帐号对应的密码是否正确，将有价值的数据通过验证的方式筛选出来，这一过程黑话叫“晒密”，意即撞库。而“晒密”最核心的障碍就是互联网公司设置的验证码安全体系。每天面对数以亿计的“晒密”需求，黑产分子不可能人工逐个识别，而是需要提高“晒密”效率，批量识别。“打码平台”这一专业服务便应运而生。
“打码平台”会与“晒密”软件作者合作：
1) 黑产团伙把盗取的帐号密码信息导入到“晒密”软件，“晒密”软件模拟登录协议，向互联网公司服务器发送登录请求。
2) 服务器检测到登录异常时，会下发验证码，进行安全策略拦截。
3) “晒密”软件将收到的验证码图片发送给“打码平台”，请求将图片转化为字符。
4) 打码平台后台破解验证码，将字符结果返回“晒密”软件，完成“晒密”（撞库）流程。
5) 这些“晒密”后得到的用户信息，则可能被骗子直接用于实施诈骗犯罪。
下面这张图，可以看到“快啊答题”打码平台所涉及的从撞库到晒密再到打码的整个黑色产业链：
早期的打码平台，对验证码的识别基本是通过“人工+OCR降维识别图片”完成。但是，互联网公司的验证码安全策略升级后，包括出现像12306这样识别难度高的验证码体系，“人工+OCR”方式的识别效率降低、成本升高，一段时期内，确实降低了黑产犯罪。
但是，黑产人员并不会因为一条路被堵死,就放弃犯罪，他们又想出了更前沿的手法来应对。目前市面上最大的 “快啊答题” 打码平台就是典型代表，他们运用目前最流行的人工智能AI技术训练机器，大大提高了识别验证码的精准度，也极大提升了犯罪嫌疑人在单位时间内识别验证码的数量。通过这个打码平台管理后台的统计信息显示，2017年1-3月，其打码量达到259亿次，平台累计打码量超过1700亿次。这套AI系统识别验证码成功率非常高，以下图红框标识处为例，当天的整体识别率会输出成日志文件，通过随机调取某日的日志文件，该日整体验证码识别率高达83.4%。
AI技术破解“晒密”低效难题
“快啊答题”打码平台基于主流AI深度学习Caffe框架，使用vgg16卷积核神经网络模型，可以直接输入原始图像（避免了对图像的复杂前期预处理），并能通过深度的机器学习来获得较高的验证码识别率。
0x03 WEB 3.0时代安全运维的困境
传统的WEB应用防火墙仍然是依赖规则（正则表达式匹配）为主来进行攻击防御，在web 2.0的时代，绝大部分的安全风险来自于web本身的各种安全漏洞，传统WAF的出现对web安全的防御确实起到了一定防护作用，帮助企业过滤了绝大部分针对已知的漏洞的攻击。但随着web 3.0的到来以及黑客攻击工具的进化和攻击思路的进化，传统WAF的运维上的桎梏开始逐渐体现。长久以来，安全和易用性一直是一对矛盾，在web 3.0时代则表现则更加明显。
1. 业务的快速发布与迭代和复杂的规则运维的矛盾
有过WAF运维经验都清楚，一般一个新的web业务上线时，基本上都有一个学习阶段，让WAF来学习一段时间，这个学习过程至少需要1个礼拜左右，学习完成之后，最后的规则还需要人工介入来确认哪些是正确的，哪些是需要调整的，基本上整下来，差不多需要10天时间；另外还有如果安全管理员对业务不熟悉的话，这个规则的确认还需要开发人员的介入，这个时间就更长了，并且开发人员都忙于满足PM的需求和修改bug，哪还有时间关注这个呢？甚至有这样一种观点——安全是麻烦的制造者：增加开发工作，增加运维要求，增加不确定性，延缓业务上线。由于时间紧任务重，业务通常还要求功能快速迭代，出现问题上线再改，对于安全部门整天提安全需求，很多人都存在抵触心理。
并且随着规则库的增多，后台业务类型的复杂（.net, apache,weblogic等不同系统），运维量成几何倍数增加，安全部门为了配合敏捷业务的发布只能是疲于奔命，疲于奔命的结果又会带来人工失误导致的安全风险。
2. 日益增加的规则库和居高不下的误报率和漏报率
未知的漏洞始终是web业务最大的安全风险，基于规则的防御方式无法防御未知的漏洞。
在配置防御规则时，如果防御规则设置的太多太严格，可能会导致误报率上升，如果防御规则设置的数量不够，又可能导致漏报率的上升，用户很难取得一个防御效果和用户体验的平衡。
3. 黑产的体系化攻击和企业的单打独斗式的防御
现在的黑客攻击已经由纯粹的基于技术的攻击逐步转向业务逻辑攻击和业务欺诈。
黑产庞大产业体系、完善的分工、隐蔽的组织性对企业的安全团队来讲，是一个非常不对称的防御作战。
0x04 应对思路及可行方法参考
面对日益增多的新业务上线和日渐猖獗的黑产，各路安全厂商也是八仙过海-各显神通。
针对WEB应用的新防护思路：
1. 通过对SQL语义理解的检测引擎进行防护。
这种方式是基于传统的规则库的防御机制进行改良。基于语义的场景的检测引擎其主要特性：
- 模型更加精细与精准（低误报率、低漏报率）
- 拥有一定的未知威胁的检测能力
- 最大限度减少规则使用，降低维护难度和出错风险
基于SQL语义理解的防御思路依然存在着一些不之处：
既然语义分析的本质在于理解，那么如果不能理解的攻击（比如新的数据库命令），自然也不可能检测。例如：假设SQL突然新增一种 findAndModify语句（从MongoDB借用），可以同时进行查找和新改的操作，那么基于语义分析的理解无法理解这种新出的语法，自然也无法判断。
因此，语义分析的防护依然需要正则规则进行救火。
另外这种思路对应于WEB攻击入侵类的防御效果有很大的提升，但对于基于机器人、爬虫的各种业务逻辑攻击则防御能力有限，因为这些业务逻辑攻击的请求完全符合各种RFC和HTTP协议规范。
2. 基于动态欺骗防御技术进行防护
这种方式是对传统的基于规则库的防御机制的一种重大补充。Gartner 在2016和2017年都将其列入10大信息安全技术的名单。其定位是通过欺骗性的技术手段来阻止和扰乱黑客攻击者的认知过程，对抗各种自动化攻击工具，提升黑客攻击难度和成本，从而达到防御的目的和效果的一种对抗技术。其主要特性为：
- 不依赖规则库即可进行防御；
- 对各种攻击工具和爬虫等业务逻辑攻击的防御能力极强；
- 对抗零日攻击的效果明显；
- 对于手工攻击的防御能力差；
- 由于不需要运维海量的规则库，运维成本大大降低；
目前国内的相关厂商也开始研究相关的技术并也推出了一些产品。
由于该技术本身尚未有明确的技术标准，因此在各个厂商的技术实现也有所不同，下面简单阐述一下主流的几种：
某厂商R的产品将大量的欺骗动作放在的浏览器端，（包括html代码动态混淆、动态令牌等），从客户的第一感觉上来说效果是最好的，但是其最大的问题在于由于前端的代码太多太重，经常会跟客户的业务代码冲突（主要是js业务代码，很多客户的部分业务逻辑都会再前端用js来实现）；另外对html代码进行动态混淆导致设备的性能偏低，其部署和维护的时间成本非常高。 
某厂商A的动态欺骗技术集中在URL部分，对WEB应用的URL采取了动态混淆，动态欺骗，多次加密及次数及时间的限制等等，通过动态隐藏URL的方式来阻止各种WEB自动攻击工具和各种爬虫、撞库及黑产，但普通用户的访问体验不受任何影响。其产品与R产品相反，前端代码非常轻量级且兼容性非常好，客户无需修改业务代码。由于其还具备传统WAF的特征库过滤功能，除了对自动化攻击防护效果突出外，对手动攻击也有一定的防护效果。
某厂商的V产品，笔者并未在实际的客户或者其他场景下测试过，但是从其官网的寥寥数语中，还是可以管中窥豹一番。
功能：支持Apache、Nginx、IIS等WEB服务器版本混淆，支持SQL注入、跨站脚本等漏洞扫描结果动态伪装，支持攻击者识别并诱捕至蜜罐节点，有效提升WEB安全。
经过对上面的描述进行分析，其本质也就是个传统的WAF，因为需要识别出来SQL注入，跨站脚本等攻击，然后只是将阻挡页面或者服务器返回的页面结果进行伪装，让攻击者无法获取攻击的结果，从而达到欺骗的目的。
3.云WAF解决方案
云WAF的解决方案通过提供SAAS服务的方式，将WAF的功能云化，帮助客户解决了WAF运维复杂的难题，有些厂商同时会提供包含CDN加速，DDOS防护在内的其他的功能，这些都是其增值功能和优势；但是随之而来的包括企业数据安全的问题、证书和私钥需要保存在SAAS服务商上、如果云WAF的SAAS服务的节点不够导致的最终用户访问web的体验会下降等等，使得云WAF的解决方案目前还只是适用于一些中小客户或者是一些start up的客户。
4.人工智能与机器学习
人工智能与机器学习很多时候是作为一种技术手段或者辅助功能出现，各个安全厂商都在这方面进行投入。由于安全产品主要是和人来进行对抗，因此安全产品的运维相对于其他的IT类产品要更加的复杂和繁琐，所以大家主要的期望和目的还是希望通过人工智能和机器学习来大大降低产品运维的复杂度或者提高安全产品的使用效率。要真正的通过人工智能或者机器学习来达到降低运维复杂度、提升运维效率的目的，需要大量的用户场景模型、每个场景下的海量日志分析及建模、以及产品本身的灵活性才有可能慢慢的落地。笔者看到，在一些大型的金融架构和互联网企业，已经开始在网络防火墙这个层面进行一些落地的机器学习的尝试，因为网络防火墙本身的场景，其日志中的信息和产品本身的配置都是相对简单。
针对WEB Service的防护思路：
另外万物互联的时代，API接口的安全成为企业web安全的另一个重要关注点，我们也会从这个方面来探索一下上述几种新的web安全思路对API接口的防御效果：
1. 对于基于语义的防御方法在面对web service的攻击时，更多的还是要依靠传统的特征库或正则表达式的方法来进行防御，因为企业客户在开发web service的时候，绝大部分都是非标准的，都是自己定义的一些接口调用方法和调用参数，用基于语义的防御方法会面临着大量未知的语境导致方法失效的问题。
2. 基于动态欺骗防御的方式在防御针对web service的攻击时，基于各个不同的实现方法，其防御效果也有所不同。对于web service 接口的地址是由服务器返回的这一类web service，动态防御类产品都可以很好的进行防护，隐藏web service的接口地址，进行动态变换和限制。
未防护情况下访问web service：
经过动态防御之后第一次访问Web Service：
第二次访问该web service接口没有结果返回，被重定向到了首页：
对于web service接口的地址是写死在客户端应用的这一类web service，则只能依靠正则规则、特征过滤来进行防护。
0x05 未完的思考
由于SSL Anywhere 时代的到来，很多安全产品的架构和部署方式上都发生了新的变化，越来越多的安全设备都使用proxy模式，一来需要对SSL流量进行解密处理，再一个是因为在proxy模式下可以实现一些复杂的安全防御功能。（本文中出现的几个新产品都是采用的proxy的架构）但大量基于proxy模式的安全设备对于企业的安全部门的管理和运维又造成了困扰。因此，笔者预判，各种基于proxy的安全厂商将会互相融合或者“吞并”的局面，各种安全设备将会被“池化”，根据业务的不同需求，按需的部署到业务上，只有这样才能在尽可能少的改动网络架构的基础上，实现众多的业务安全需求。
在这种部署架构下，网络防火墙和负载均衡都是基础网络架构设备，其他各种安全服务设备部署在DMZ1区，通过负载均衡设备来提供动态的安全资源服务，同时负载均衡设备可以帮助解决安全设备的高可用的问题、性能扩展的问题，并且还可以提供SSL卸载的功能，来大大降低SSL对安全设备的性能压力。
访问数据流如下：网络防火墙à安全池负载均衡设备à安全服务设备à网络防火墙àWEB服务器-负载均衡设备àWEB服务器。从访问数据流上来看，数据流多了一层处理环节，但这也是在目前大多数的网络架构下比较可行的一种部署方案，并且该方案可以按照业务来进行安全防护，其上线和回退通过与负载均衡设备进行联动都非常的迅速，不会出现“一损俱损”的局面。
WEB 3.0时代，web安全已经扩展到了业务安全，“矛”和“盾”的斗争又提升到了新的层次，这也鞭策着我们网络安全从业人员不断创新，从更多的角度和维度来思考，希望有更多新的技术和产品的出现来帮助我们的客户，可以去从容的面对业务安全的威胁。
注: 部分资料和截图来自网络，版权归作者所有，任何形式转载请联系作者