此文刊登在《程序员》三月期，有删改

提到安全问题，首先想到应付这些问题的应该是系统管理员以及后台开发工程师们，而前端开发工程师似乎离这些问题很遥远。然而，在 2008 年发生在安全领域的一系列 Web 安全事件，改变了人们对于传统安全的观念。让我们在这里简要回顾下：

IE7 的 0day 漏洞以及 Chrome 崩溃事件

2008 年的年底， IE7 爆出了个很严重的安全漏洞 。与往期微软的漏洞不同，这次的漏洞是从 IE7 发布时起就存在（这也是称之为 0day 漏洞的原因）。

该漏洞的原理，就是通过解析某段精心构造的 XML 造成 IE7 内存溢出，进而可执行任意的代码。虽然官方很快发布了此漏洞的补丁，但此漏洞仍然影响至今。

另个类似的浏览器风波，就是 Google 在 08 年 Q3 发布 Chrome 浏览器。在 Chrome 发布当天，黑客们就发现只要在地址栏中输入构造好的字符就能导致浏览器崩溃。此后即便 Google 迅速的修复了该漏洞，但已经对用户造成了非常糟糕的印象。

感叹：浏览器平台的安全问题，直接影响着该浏览器日后的市场份额。好比当年 Firefox 起家时也正因着重打安全这张重牌，才有今日的收获。即将推出的 IE8 浏览器，微软已经在各种场合大肆宣扬该新浏览器的安全性能。由此，正说明各浏览器厂商对安全这块的重视程度。相信目前正酣的浏览器战场，对于安全这块必然是兵家必争之地。

各微博客的 CSRF 和 Clickjacking 漏洞

微博客的流行是 Web2.0 大潮中的奇葩，然而近期爆发的 饭否、叽歪、Twitter 等的安全漏洞，着实让前端开发工程师大开眼界。 饭否 和 叽歪 的 CSRF 漏洞 ，使得攻击者能通过段 Javascript 代码在用户不知情的情况下，向微博客服务器发布相应的消息，从而造成攻击。

感叹：客户端的 Javascript 脚本早已经摆脱仅仅是显示页面效果的「玩具」，它已经变成一把利刀。这把刀能帮前端解决问题的同时，也能伤害到用户。

同比，年初爆发的 Twitter Clickjacking 漏洞 ，它将 Twitter 的发布页面通过 iframe 嵌入到第三方页面，然后通过 CSS 使得并将 Twitter 的发布按钮与第三方页面的按钮重合。这样，当用户本意点击第三方页面的按钮时，实际上点击的是 Twitter 页面的发布按钮，进而造成攻击。

感叹：前端攻击方式也正逐渐的升级，防范前端代码的攻击不仅仅就是防范 Javascript 等前端脚本，CSS 甚至 HTML 也能构成攻击。

「精武门」安全峰会

「精武门」安全峰会是阿里巴巴集团组织的针对 Web 应用安全的研讨会。和往年讨论后台安全不同，今年重点着重讨论 Web 攻击的方式和防范。众多国内著名的安全小组集聚一堂，讨论目前国内 Web 应用的前端安全问题。

感叹：在见识了琳琅满目的攻击方式的同时，也引发了对于未来国内 Web 应用安全的思考。

后记

Web 2.0 以降，前端这个职位已从传统「美工」，蜕变成用户体验的实现者。然而随着浏览器提供的功能日益强大、各种 Web 应用的日趋复杂，安全这块被传统笼罩的「灰色地带」，也正进入每个前端开发工程师的视线。相信在不久的将来，前端开发工程师作为新生的安全力量，必占有十分重要的一席。

最近的 Twitter 的 Clickjacking 漏洞 值得我们注意下。

这个漏洞的原理，就是将 Twitter 的发布页面 通过 iframe 载入到第三方页面。然后将 iframe 透明度设置成零，并将发布按钮与第三方页面的按钮重合。当用户本意点击第三方页面的按钮时，实际上点击的是 Twitter 页面的发布按钮（ 详细 ）。

由于 Twitter 中的好友基本上都是熟人，加之好奇心的驱使很多人都会点击该按钮，因此很快就被传播开来。不过很快截止目前（2009-02-12）， Twitter 官方已经修复了该漏洞 。

官方的修复方式较简单，就是判断页面是否被 iframe 引入，如有则清空 body 节点的内容。而个人认为，这是非常偷懒而且治标不治本的的解决办法。

首先，既然清空页面（还做了个延时，又那么多的 DOM 操作，费时又费力），那何不直接跳转？其次，就是发现 Twitter 将几乎所有的 Web 版页面都加入了这段代码，有点杀鸡取卵的意思。再加个「马后炮」，其实这个页面压根就可以不用处理 $_GET['status'] 请求。

看了下代码，发现 Twitter 发布页同时包含了个 Javascript 的全局变量 twttr.form_authenticity_token，-- 我想你知道干嘛用的 （当然，前提条件是你怎么得到它）。

另外，还有个安全隐患，就是 移动版的 Twitter 页面 。手机页面由于没有过多的考虑 Javascript 操作，也就没有了上述的那段代码，但这意味着 Clickjacking 攻击其实在此页面还是存在的。

上图是将此页面加入到 iframe 的效果，感谢 玉伯 同学的测试，剩下就打住不继续说了。

几点心得和感叹

1. 前端代码在实现越来越丰富的应用的同时，也给安全问题划开了道巨大的口子
2. Twitter 此法虽然也解决了该漏洞，但个人感觉并非常「不完美」。这就想起在平时，需要用什么方法才能恰当的搞定相应的需求
3. 老生常谈， 避免 Javascript 全局变量 -- 没有不注意它的理由
4. 漏洞的解决尽可能覆盖到所有的产品线，捡了西瓜的同时还得捡起芝麻

根据 Dotzler 的统计 ，IE6 的份额正在缩水，这可能是 2009 年本人听到的第一个好消息。于此同时， Gmail 的浏览器支持列表中已经将 IE6 给剔除 ，Google 官方 推荐用户使用 Firefox 或者 Chrome 可获得双倍的速度和用户体验。

那么， 似乎又回到 了 IE6 的话题。

IE6 为什么存在着？

IE6 的发布时间可以追溯到 2001 年的 Windows XP 的发布。是的，IE6 已经成为了世上最「长寿」的浏览器。而问题是，IE6 为什么能够如此顽强的存在着。抛砖引玉，本人先列举几条，欢迎补充：

操作系统的「潜规则」

Windows 系统和 IE 紧紧的捆绑，使得升级浏览器变得如履薄冰。正如我们看到的，几年来 Windows 系统的补丁也仅仅是在原有的基础上缝缝补补 -- 微软显然不愿冒这个风险。

Vista 的失败

Vista 已经变成了第二个 Windows ME 。撇开这个先不谈，用户升级浏览器的另种情况，就是操作系统的升级。Vista 商业上的失败，注定 IE6 搭载的 XP 这艘船能够续航更长的一段时间。

IE7 也不是什么好鸟

2006 年底发布的 IE7 远远的没有达到市场的预期。从当时的 IE7 发布情况看，注定 IE7 只是个过渡性的产品。

IE8 开发进展缓慢，并远被甩在了后面

「现在这个功能，我们也有了」， D2 上微软兄弟幽默的言语 也折射出一个事实，目前根本就没有用户敢用 IE8。IE6-8 三个版本并存的混乱局面，越发说明了微软的这个坑是被自己越挖越大、越挖越深了。

普通用户不在乎

是的，这是事实。普通用户而言，上网仅仅是双击某个图标，输入某个网址就可以。他不了解什么是浏览器，当然也没必要了解。对于他们而言，能够完成自己的目标才是最重要的。

国内「特殊的情况」

譬如：国内的软件几乎都是免费的，获取没有任何的成本、国内的教程几乎都是介绍怎么使用 Dreamweaver、 Firefox 在国内病毒式的推广 ，在部分「不明真相」的用户心中，俨然已经是恶意软件的代名词，等等…

「2009 年，IE6 真的会消亡吗」

那么，在接下来的 2009 年，IE6 真的会消亡吗？在本人看来，至少不会完全消亡。IE6 的完全消亡，需要我们大家共同的参与。例如，作为名前端（或者其他与浏览器打交道的兄弟），应该怎么做？

浏览器的表现不完全一致

不同的浏览器提供的功能和性能不完全一致，所以页面没必要在所有的浏览器中完全的一致。我们要让我们的同伴、用户了解，至少那 2001 年发布的浏览器所表现的性能，不可能和现代的浏览器完全一致。

对于 IE6 的优雅降级

我们可以尝试先丢下 IE6 的包袱，开始针对现代的浏览器开发，然后 优雅的降级 到老版本的浏览器。例如，我们可以高版本的 CSS 特性，然后再针对 IE6 使用单独的脚本去实现它。

继续布道

我们要让更多的人了解 IE6 是个糟糕的浏览器，并推荐他们使用更好的浏览器，譬如 Firefox、Chrome 等。

-- Split --

最后，解铃还须系铃人。2009 年微软 即将发布的 Windows7 ，从另个侧面也将推动 IE6 的灭亡。总之，09 新年伊始，是时候给那老态龙钟的 IE6 钉上棺材钉了。