無標題文檔

前端也应关注安全

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

提到安全问题,首先想到应付这些问题的应该是系统管理员以及后台开发工程师们,而前端开发工程师似乎离这些问题很遥远。然而,在 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 的 Clickjacking 漏洞 值得我们注意下。

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

https://gracecode.b0.upaiyun.com/2009_02_13/1234539040.jpg

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

https://gracecode.b0.upaiyun.com/2009_02_13/1234539182.png

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

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

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

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

https://gracecode.b0.upaiyun.com/2009_02_13/1234539386.png

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

几点心得和感叹

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

2009 年,IE6 走好

https://gracecode.b0.upaiyun.com/2009_01_03/1230920848.png

根据 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 钉上棺材钉了。

「我们是前端」

周六与朋友一起,相互分享自己的新知。本人较懒,没有做过多的准备,简单的分享了下对前端这个职位的理解( 下载 PPT )。

其中主要讲述了前端及其职能、前端的项目开发流程等方面。这些内容 其实 圆心 已经非常详细的解说过了 ,本人也是即学即用。

前端这个职位目前在国内还是比较「新鲜」的,很多人都不了解前端具体是做什么。而可以预见的是,通过 D2 、相互分享等渠道,前端这个职位将会被越来越多的人所知。

最后,获得四个很受用的关键字

激情、执着、开放、谦逊

上述我想不仅仅是前端,也应是所有的开发人员,都值得去努力做到的。

IE6 方程式(翻译)

<!--[if lt IE 7]>
    <script src="http://ie7-js.googlecode.com/svn/version/2.0(beta3)/IE7.js" 
        type="text/javascript"></script>
<![endif]-->

兼容标准的浏览器并不会运行此段脚本(对于他们而言仅仅是注释而已)。如果访问者使用的是 IE6 这糟糕的浏览器,就会额外的下载这段 Javascript 脚本。

那么问题是,什么时候应该编写额外的 IE6 样式,而什么时候应该做的仅仅是引入那段 Dean Edwards 编写的脚本呢?详细的回答这个问题,可能需要花费我和我的同事 Natalie Downe 整个上午的时间。然而回答这个问题之前,您首先需要了解并回答两个问题:「在针对 IE6 上的开发时间有多少?」以及「有多少访问者正在使用的 IE6 ?」。

让我们使用 t 表示总的开发时间、t6 表示花在 IE6 上的时间;所有的访问者数目表示为 a、 a6 则表示正在使用 IE6 的访问者。本人和那伙极具数学细胞的伙伴 Cennydd Bowles 和 Natalie 定义了下面的公式,用于量化的计算有多大的权重去使用上述 Dean Edwards 的 IE7 脚本。

https://gracecode.b0.upaiyun.com/2009_11_05/004696a19db9.jpg

p = 50 [ log ( at6 / ta6 ) + 1 ]

你可以尝试计算下属于你自己的数字。比如你花了大量的时间在 IE6 上,但只有很小部分访问者使用该浏览器,那么你可能会获得个非常高的数字。这意味着你可以使用 IE7 脚本。而反过来,如果使用较少的时间处理 IE6 的问题,或者你的大部分访问者都在使用 IE6 浏览器,那么那个 p 值会很小,这时你应该另外编写针对 IE6 的样式。

当然,实际情况是使用这个方程式显得有点自欺欺人。你可以很容易获得使用 IE6 的访问者占总访问者的比例数,但然而获得精确花费在 IE6 上的开发时间却显得相当的困难 - 或许需要当你完成了总的开发计划以后,才能得出具体所占的时间,而到那时这个方程式已经显得有点「马后炮」了。

替代上述方程式的另个方案,可以尝试下限制花费在 IE6 上的开发时间。具体是首先让你的站点与标准保持兼容,然后计划针对 IE6 上的开发时限。如果不能在这个时限内解决问题,那么替代使用 Dean Edwards 的脚本。

这一具体的占用时间可考虑和访问者使用 IE6 所占的比例进行计算。比如 20% 的访问者仍然在使用 IE6,同时你使用了 5 天开发时间完成了兼容标准的站点,那么就可以限定 1 天时间集中解决 IE6 的问题;但如果有 50% 的访问者仍然在使用着 IE6,那么你可能需要准备 2.5 天时间去解决这些问题。

所有这些针对 IE6 的处理方式的讨论没有绝对唯一的答案,同时也不可能适用于每个人。如何处理 IE6 这个棘手的问题仍然是当前的焦点之一,目前互联网上不少的 Blog、文章甚至站点都在讨论什么时候应该放弃支持 IE6。但他们没有明确的定义他们所谓的 「支持」具体是何意 。当然这不是个简单的「是」或者「非」就能回答的问题。作为替代,下面有个不同层级的支持方案:

上述每个条目获得的最终结果可能是非常极端的。本人不赞成开发人员积极的抵制任何一款浏览器,也同时认为使用那些过时的浏览器的访问者获得的体验,与那些使用现代的浏览器的用户获得的不可能完全一致。真正的要点在于,IE6 被我们放在「支持」与「不支持」之间的哪个平衡点之间。

正如我认为标记语言最重要的是语义,上述的观点在 Web 开发中同样的重要。我们尝试获得更好的方式,这总要比那挂在口头的冰冷动词「支持(support)」显得更为的重要。如果你向你的访问者保证你的站点「支持」 IE6,那么你得了解更深一层的含义。相反的,如果你表明将「不支持」 IE6,那么你同样需要花点时间思考为什么需要这样做。

最后,Yahoo 的 Web 开发人员提出的 浏览器分级 概念我很认同。当然有其他的想法,我同样会有兴趣去倾听。如果我们都步调一致的发出自己的心声,那么最终我们会以更好的姿态去击败共同的对手!

我的照片

嗨!我叫「明城」,八零后、技术男、伪苹果粉、微软无脑黑、宁波佬,现居杭州。

除了我的博客,同时也欢迎您访问我的 GitHubTwitterInstagram 主页。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 其实无所谓叫什么名字,因为我曾经为这个名字伤透了脑筋。最后想到的这个名字都没啥特别的,说到 底是因为我实在给它不了个非常酷的名字。

如果您想联系我,可以发我邮件 echo bWluZ2NoZW5nQG91dGxvb2suY29tCg== | base64 -d

注:本站点所持观点仅代表个人意见,不代表所服务公司的立场。

文章

项目

微信公众号