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

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

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

https://friable.rocks/_/2009_02_05/1233811266.png

那么我们来看下 updateStatus 的脚本 是怎么写的(通过这个脚本,也可大体的了解叽歪的 API):

https://friable.rocks/_/2009_02_05/1233811318.png

发现 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);

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

https://friable.rocks/_/2009_11_05/419606edd996.jpg

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

最后,啰嗦下防范 CSRF 攻击 的「军规」:

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

后记

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

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