记得郭德纲有这么一个著名的段子：家中屋漏，外面下小雨，屋里下大雨；外面下大雨，全家人就只能站到院子里避雨。如果我们把屋子换成伞，外面下雨，伞里也下雨，你还会用这样的伞吗？
“简直是笑话，谁会用这样的伞？”，你可能会这么说。不过，是不是有漏雨的伞，咱先别着急下结论。这凡事都有个体验和比较。没有体验和比较，你就不知道到底什么样的伞叫好伞。
在前两天阿里云论坛的安全版块里有这么一个有趣儿的热帖。在这个帖子里，楼主讲了这么一个有趣儿的事儿：“我现在操作2个网站： 一个心理测试大百科www.A.com，部署在阿里云，开通云盾。另 一个是www.B.cn，部署在XX数码。 昨天这2个网站后台都发现了同样的警告框。但是只有XX数码上的www.B.cn中招了。 2个程序版本一样，为什么阿里云上的心理测试大百科www.A.com没中招呢? ”
楼主所谓的“中招”是指在他采用PHPCMS系统的网站后台多了一个超级管理员用户－pcmanage。而这个pcmanage超管用户并非他自己添加，而是被别人偷偷地加上去的。
好个从石头缝里蹦出来的孙悟空。开过网站的小伙伴想必都应该非常清楚事情的严重性了。PHPCMS系统的“超级管理员”就像它的命名一样，拥有对网站系统的一切权限。如果黑客拥有了攻击目标网站的超级管理员账号，后果可想而知。
那么，黑客是如何偷偷添加超级管理员账号的呢？简言之，黑客利用PHPCMS系统的0day漏洞，窃取了网站专门用来防护跨站攻击的Token，通过劫持管理员的HTTP会话，在管理员丝毫没有察觉的情况下，利用管理员的身份成功添加了超级管理员账户——一个无所不能的孙悟空。
有些拗口，别急，下面我们详细说说黑客是怎么攻击的。经过阿里云安全技术团队的分析，黑客当时是利用了PHPCMS系统存在的一个漏洞发起了CSRF攻击，最终添加了超管账号。
CSRF（Cross-site request forgery），中文名称跨站请求伪造，是在用户会话下通过第三方网站发起GET/POST的请求——这些请求用户未必知道和愿意做，可以把它视作一种HTTP会话劫持。下图是典型的CSRF攻击过程：
图1: CSRF典型攻击过程
从上图可以看出，A网站通过cookie来识别用户（C），当用户成功进行身份验证之后浏览器就会得到一个标识其身份的cookie，只要不关闭浏览器或者退出登录，以后访问A网站会一直带上这个cookie。如果这期间浏览器被人控制着向A网站发起请求去执行一些用户不想做的功能（比如添加账号），这就是会话劫持了。因为这个不是用户真正想发出的请求，这就是所谓的“请求伪造”。此外，由于请求可以从第三方网站提交，所以前缀跨站二字，即从B网站发起。
PHPCMS系统对于CSRF的防护主要是通过在会话中加入令牌（Token）方式来实现，黑客恰恰是利用了0day漏洞在偷窃了Token后，发起了CSRF攻击并劫持了管理员的身份。
面对这样一个0day漏洞攻击，阿里云云盾如何实现有效防护的呢？众所周知，0day漏洞是没有补丁的，客观地讲，在防护的时候也无法采用针对性的防护手段。然而，阿里云云盾多层面纵深化防护体系对于未知攻击同样可以做到有效防护。
云盾在网络、系统以及应用上均有相应的防护策略，这些防护策略对于网站来说，就像一层层的防护网。更为关键的是，这些“防护网”是一体化的，是一个整体，并非彼此孤立。无论在网络流量攻击、还是系统入侵或是应用破坏上，黑客只要在入侵过程中触发任何一个防护点的策略，均会引发云盾整体的迅速响应。在上面的攻击过程中，由于黑客采取了“组合化”进攻手段，触发了云盾对某单项攻击手段的防护策略，从而导致整个攻击过程戛然而止。
既有点，也有面，点面结合，这正是云盾强大的地方。这种点面结合的整体防护体系考验的是多个安全子系统能否实现彼此无缝配合、策略分布式部署以及面向攻击的整体化视野。这样的防护体系不是简单部署一个DDoS防护系统、入侵防御系统或WAF系统就可以实现。
传统IDC数据中心普遍采取糖葫芦串式的防护手段，在服务器前部署一长串的防护设备，这些防护设备之间是独立工作，没有彼此关联关系。这种安全防护模型无疑增加了防御一方的建设和运营管理成本，而面对0day或者更为复杂攻击的时候却往往束手无策。
事实上，强大的云盾也不是一朝锻造而成，而是得益于阿里安全部十年攻防积累的数据和经验。其全面的DDoS防护、主机入侵防护、Web防护墙以及贴心而全面的网站安全体检服务，也是几十万网站站长选择阿里云的重要原因。
最后，再回到文章开始时候提到的雨伞。这伞好不好，最关键还是要看漏不漏雨；而漏雨不漏雨，只有用过的人才知道。
