声明，此漏洞已提交叽歪官方处理（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" />