声明,此漏洞已提交叽歪官方处理(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 攻击 的「军规」:
- 在请求中使用 Security token
- 正确使用 GET、POST 和 Cookie
- 使用 Referer 判断请求来源
后记
截止发文时(2009-02-07),叽歪已经修复了该漏洞,增加了个 Security token :
<input type="hidden" value="..." name="crumb" />