最近的 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. 漏洞的解决尽可能覆盖到所有的产品线，捡了西瓜的同时还得捡起芝麻

这段时期由于 找到几个线上的漏洞 ，勾起了兄弟们对于安全方面的兴趣。我也正好乘热打铁，做了个简单的分享（ 在线观看 / 下载 ）。主要内容有：

1. 前端同样应该关注安全
2. 典型的 Web 攻击方式（XSS、CSRF 等）

虽然内容不是很多，但结合实例，能让我们的组员能对安全这块的感兴趣，我想就已经达到目的了 :^)

声明，此漏洞已提交叽歪官方处理（2009-02-05），本案例仅作技术研究。由此漏洞造成的所有后果，本人不承担任何责任。

参加集团「精武门」安全峰会时， 80sec 团队对于饭否的 CSRF 蠕虫攻击 案例还记忆犹新。抱着对比的心态，逐个检测国内各微博客类站点的安全性能，最终「很不幸」的锁定到了 叽歪 上。

分析 叽歪页面发布信息页面 的表单，结果发现全部都是交给 updateStatus 方法处理，如图

那么我们来看下 updateStatus 的脚本 是怎么写的（通过这个脚本，也可大体的了解叽歪的 API）：

发现 updateStatus 的脚本非常简单，就是检测下 textarea 的值是否为空（其实那样敲几个空格就可以绕过），然后就提交给服务器处理。而且逻辑上似乎有问题，返回的都是 false （或许是为了防止事件冒泡）。

既然 Javascript 方面没有增加额外的提交参数，这说明在 Javascript 禁用的情况下提交表单服务器那边也是能处理的。那么，根据叽歪发布页面的表单，尝试本地构建个同样的表单发送叽歪信息

<form action="http://jiwai.de/wo/status/update" method="post">
    <textarea name="jw_status" ></textarea>
    <input type="submit" />
</form>

结果成功了。这表明有存在 CSRF 的可能 -- 用户可以自行表单，发送信息给叽歪服务器处理，并且没有任何验证信息。

然后，非常「邪恶」地将 POST 方式改成 GET 尝试，结果发现又成功了。看来叽歪的接口没有区分 POST 和 GET，那么这样攻击的危害更扩大了层。

根据这个漏洞，简单的写了个本地 Javascript 脚本，尝试每隔一秒发送叽歪信息

setInterval(function() {
    var img = new Image();
    var message = '明城很帅';
    var api = 'http://jiwai.de/wo/status/update';
    img.src = api + '?jw_status=' + message + '&t=' + new Date().getTime();
}, 1000);

剩下就是社会学的范畴了。想到 沉鱼 小姑娘是叽歪的重度用户，于是让她打开这个页面（这时候，相貌是多么的重要）。

结果自然是预期所想的，顺便发现叽歪也没有限制发送信息的频率。就这样打住，通过这个漏洞进行蠕虫等进一步攻击等已是唾手可得。

最后，啰嗦下防范 CSRF 攻击 的「军规」：

1. 在请求中使用 Security token
2. 正确使用 GET、POST 和 Cookie
3. 使用 Referer 判断请求来源

后记

截止发文时（2009-02-07），叽歪已经修复了该漏洞，增加了个 Security token :

<input type="hidden" value="..." name="crumb" />