2.3 XSS的魔力

跨站腳本（Cross-Site Scripting，XSS）是一種網(wǎng)站應(yīng)用程序的安全漏洞攻擊，是代碼注入的一種，允許惡意用戶將代碼注入網(wǎng)頁，其他用戶在觀看網(wǎng)頁時(shí)會(huì)受到影響。這類攻擊通常包含HTML和用戶端腳本語言。

XSS攻擊通常是指通過利用網(wǎng)頁開發(fā)時(shí)留下的漏洞，巧妙注入惡意指令代碼到網(wǎng)頁，使用戶加載并執(zhí)行攻擊者惡意制造的網(wǎng)頁程序。這些惡意網(wǎng)頁程序通常是JavaScript，但實(shí)際上可以包括Java、VBScript、ActiveX、Flash或者普通的HTML。攻擊成功后，攻擊者可能得到更高的權(quán)限（如執(zhí)行一些操作）、私密網(wǎng)頁內(nèi)容、會(huì)話和Cookie等內(nèi)容。（摘自維基百科）

如上所述，XSS攻擊是代碼注入的一種。時(shí)至今日，瀏覽器上的攻與防片刻未歇，很多網(wǎng)站給關(guān)鍵Cookie增加了HTTP Only屬性，這意味著執(zhí)行JavaScript已無法獲得用戶的登錄憑證（即無法通過XSS攻擊竊取Cookie登錄對(duì)方賬號(hào)），雖然同源策略限制了JavaScript跨域執(zhí)行的能力，但是XSS攻擊依然可以理解為在用戶瀏覽器上的代碼執(zhí)行漏洞，可以在悄無聲息的情況下實(shí)現(xiàn)模擬用戶的操作（包括文件上傳等請(qǐng)求）。CTF比賽中曾數(shù)次出現(xiàn)這種類型的XSS題目。

2.3.1 XSS漏洞類型

1．反射/存儲(chǔ)型XSS

根據(jù)XSS漏洞點(diǎn)的觸發(fā)特征，XSS可以粗略分為反射型XSS、存儲(chǔ)型XSS。反射型XSS通常是指惡意代碼未被服務(wù)器存儲(chǔ)，每次觸發(fā)漏洞的時(shí)候都將惡意代碼通過GET/POST方式提交，然后觸發(fā)漏洞。存儲(chǔ)型XSS則相反，惡意代碼被服務(wù)器存儲(chǔ)，在訪問頁面時(shí)會(huì)直接被觸發(fā)（如留言板留言等場(chǎng)景）。

這里模擬一個(gè)簡單的反射型XSS（見圖2-3-1），變量輸入點(diǎn)沒有任何過濾直接在HTML內(nèi)容中輸出，就像攻擊者對(duì)HTML內(nèi)容進(jìn)行了“注入”，這也是XSS也稱為HTML注入的原因，這樣我們可以向網(wǎng)頁中注入惡意的標(biāo)簽和代碼，實(shí)現(xiàn)我們的功能，見圖2-3-2。

然而這樣的payload會(huì)被Google Chrome等瀏覽器直接攔截，無法觸發(fā)，因?yàn)檫@樣的請(qǐng)求（即GET參數(shù)中的JavaScript標(biāo)簽代碼直接打印在HTML中）符合Google Chrome瀏覽器XSS過濾器（XSS Auditor）的規(guī)則，所以被直接攔截（這也是近年來Google Chrome加強(qiáng)防護(hù)策略導(dǎo)致的。在很長一段時(shí)間內(nèi)，攻擊者可以肆意地在頁面中注入XSS惡意代碼）。換用FireFox瀏覽器，結(jié)果見圖2-3-3。

輸入的數(shù)據(jù)被拼接到HTML內(nèi)容中時(shí)，有時(shí)被輸出到一些特殊的位置，如標(biāo)簽屬性、JavaScript變量的值，此時(shí)通過閉合標(biāo)簽或者語句可以實(shí)現(xiàn)payload的逃逸。

又如，下面的輸入被輸出到了標(biāo)簽屬性的值中（見圖2-3-4），通過在標(biāo)簽屬性中注入on事件，我們可以執(zhí)行惡意代碼，見圖2-3-5。在這兩種情況下，由于特征比較明顯，因此使用Google Chrome瀏覽器的時(shí)候會(huì)被Google Chrome XSS Auditor攔截。

第三種情況是我們的輸入被輸出到JavaScript變量中（見圖2-3-6），這時(shí)可以構(gòu)造輸入，閉合前面的雙引號(hào)，同時(shí)引入惡意代碼（見圖2-3-7）。

可以看到，這次頁面源碼并沒有變紅，意味著Google Chrome并未攔截這個(gè)輸入，訪問成功彈框，見圖2-3-8。

前三種是XSS中最簡單的場(chǎng)景，即輸入原封不動(dòng)地被輸出在頁面中，通過精心構(gòu)造的輸入，使得輸入中的惡意數(shù)據(jù)混入JavaScript代碼中得以執(zhí)行，這也是很多漏洞的根源所在，即：沒有很好地區(qū)分開代碼和數(shù)據(jù)，導(dǎo)致攻擊者可以利用系統(tǒng)的缺陷，構(gòu)造輸入，進(jìn)而在系統(tǒng)上執(zhí)行任意代碼。

2．DOM XSS

簡單來講，DOM XSS是頁面中原有的JavaScript代碼執(zhí)行后，需要進(jìn)行DOM樹節(jié)點(diǎn)的增加或者元素的修改，引入了被污染的變量，從而導(dǎo)致XSS，見圖2-3-9。其功能是獲取imgurl參數(shù)中的圖片鏈接，然后拼接出一個(gè)圖片標(biāo)簽并顯示到網(wǎng)頁中，見圖2-3-10。

輸入并不會(huì)直接被打印到頁面中被解析，而是等頁面中原先的JavaScript執(zhí)行后取出我們可控的變量，拼接惡意代碼并寫入頁面中才會(huì)被觸發(fā)，見圖2-3-11。

可以看到，惡意代碼最終被拼接到了img標(biāo)簽中并被執(zhí)行。

3．其他場(chǎng)景

決定上傳的文件能否被瀏覽器解析成HTML代碼的關(guān)鍵是HTTP響應(yīng)頭中的元素Content-Type，所以無論上傳的文件是以什么樣的后綴被保存在服務(wù)器上，只要訪問上傳的文件時(shí)返回的Content-type是text/html，就可以成功地被瀏覽器解析并執(zhí)行。類似地，F(xiàn)lash文件的application/x-shockwave-flash也可以被執(zhí)行XSS。

事實(shí)上，瀏覽器會(huì)默認(rèn)把請(qǐng)求響應(yīng)當(dāng)作HTML內(nèi)容解析，如空的和畸形的Content-type，由于瀏覽器之間存在差異，因此在實(shí)際環(huán)境中要多測(cè)試。比如，Google Chrome中的空Content-type會(huì)被認(rèn)為是text/html，見圖2-3-12，也是可以彈框的，見圖2-3-13。

2.3.2 XSS的tricks

1．可以用來執(zhí)行XSS的標(biāo)簽

基本上所有的標(biāo)簽都可以使用on事件來觸發(fā)惡意代碼，比如：

效果見圖2-3-14。

另一個(gè)比較常用的是img標(biāo)簽，效果見圖2-3-15。

由于頁面不存在路徑為/x的圖片，因此直接會(huì)加載出錯(cuò)，觸發(fā)onerror事件并執(zhí)行代碼。

其他常見的標(biāo)簽如下：

2．HTML5特性的XSS

HTML5的某些特性可以參考網(wǎng)站http://html5sec.org/。很多標(biāo)簽的on時(shí)間觸發(fā)是需要交互的，如鼠標(biāo)滑過點(diǎn)擊，代碼如下：

input標(biāo)簽的autofocus屬性會(huì)自動(dòng)使光標(biāo)聚焦于此，不需交互就可以觸發(fā)onfocus事件。兩個(gè)input元素競(jìng)爭焦點(diǎn)，當(dāng)焦點(diǎn)到另一個(gè)input元素時(shí)，前面的會(huì)觸發(fā)blur事件。例如：

3．偽協(xié)議與XSS

通常，我們?cè)跒g覽器中使用HTTP/HTTPS協(xié)議來訪問網(wǎng)站，但是在一個(gè)頁面中，鼠標(biāo)懸停在一個(gè)超鏈接上時(shí)，我們總會(huì)看到這樣的鏈接：javascript：void（0）。這其實(shí)是用JavaScript偽協(xié)議實(shí)現(xiàn)的。如果手動(dòng)單擊，或者頁面中的JavaScript執(zhí)行跳轉(zhuǎn)到JavaScript偽協(xié)議時(shí)，瀏覽器并不會(huì)帶領(lǐng)我們?nèi)ピL問這個(gè)地址，而是把“javascript：”后的那一段內(nèi)容當(dāng)作JavaScript代碼，直接在當(dāng)前頁面執(zhí)行。所以，對(duì)于這樣的標(biāo)簽：

單擊這個(gè)標(biāo)簽時(shí)并不會(huì)跳轉(zhuǎn)到其他網(wǎng)頁，而是直接在當(dāng)前頁面執(zhí)行alert（1），除了直接用a標(biāo)簽單擊觸發(fā)，JavaScript協(xié)議觸發(fā)的方式還有很多。

比如，利用JavaScript進(jìn)行頁面跳轉(zhuǎn)時(shí)，跳轉(zhuǎn)的協(xié)議使用JavaScript偽協(xié)議也能進(jìn)行觸發(fā)，代碼如下：

所以如果在一些登錄/退出業(yè)務(wù)中存在這樣的代碼：

即跳轉(zhuǎn)的地址是我們可控的，我們就能控制跳轉(zhuǎn)的地址到JavaScript偽協(xié)議，從而實(shí)現(xiàn)XSS攻擊，見圖2-3-16。

另外，iframe標(biāo)簽和form標(biāo)簽也支持JavaScript偽協(xié)議，感興趣的讀者可以自行嘗試如下。不同的是，iframe標(biāo)簽不需交互即可觸發(fā)，而form標(biāo)簽需要在提交表單時(shí)才會(huì)觸發(fā)。

除了JavaScript偽協(xié)議，還有其他偽協(xié)議可以在iframe標(biāo)簽中實(shí)現(xiàn)類似的效果。比如，data偽協(xié)議：

4．二次渲染導(dǎo)致的XSS

后端語言如flask的jinja2使用不當(dāng)時(shí)，可能存在模板注入，在前端也可能因?yàn)檫@樣的原因形成XSS。例如，在AngularJS中：

上面的代碼會(huì)將參數(shù)t直接輸出到AngularJS的模板中，在我們?cè)L問頁面時(shí)，JavaScript會(huì)解析模板中的代碼，可以得到一個(gè)前端的模板注入。AngularJS引擎解析了表達(dá)式“3*3”并打印了結(jié)果，見圖2-3-17。

借助沙箱逃逸，我們便能達(dá)到執(zhí)行任意JavaScript代碼的目的。這樣的XSS是因?yàn)榍岸藢?duì)某部分輸出進(jìn)行了二次渲染導(dǎo)致的，所以沒有script標(biāo)簽這樣的特征，也就不會(huì)被瀏覽器隨意的攔截，見圖2-3-18。

參考鏈接：https://portswigger.net/blog/XSS-without-html-client-side-template-injection-with-angularjs。

2.3.3 XSS過濾和繞過

過濾的兩個(gè)層為WAF層、代碼層。WAF（Web Application Firewall，Web應(yīng)用防火墻）層通常在代碼外，主機(jī)層對(duì)HTTP應(yīng)用請(qǐng)求一個(gè)過濾攔截器。代碼層則在代碼中直接實(shí)現(xiàn)對(duì)用戶輸入的過濾或者引用第三方代碼對(duì)用戶輸入進(jìn)行過濾。

JavaScript非常靈活，所以對(duì)于普通的正則匹配，字符串對(duì)比很難攔截XSS漏洞。過濾的時(shí)候一般會(huì)面臨多種場(chǎng)景。

1．富文本過濾

對(duì)于發(fā)送郵件和寫博客的場(chǎng)景，標(biāo)簽是必不可少的，如嵌入超鏈接、圖片需要HTML標(biāo)簽，如果對(duì)標(biāo)簽進(jìn)行黑名單過濾，必然出現(xiàn)遺漏的情況，那么我們可以通過尋找沒有被過濾的標(biāo)簽進(jìn)行繞過。

我們也可以嘗試fuzz過濾有沒有缺陷，如在直接把script替換為空的過濾方式中，可以采用雙寫形式<scrscriptipt>；或者在沒有考慮大小寫時(shí)，可以通過大小寫的變換繞過script標(biāo)簽，見圖2-3-19。

錯(cuò)誤的過濾方式甚至可以幫助我們繞過瀏覽器的XSS過濾器。

2．輸出在標(biāo)簽屬性中

如果沒有過濾“<”或“>”，我們可以直接引入新的標(biāo)簽，否則可以引入標(biāo)簽的事件，如onload、onmousemove等。當(dāng)語句被輸出到標(biāo)簽事件的位置時(shí)，我們可以通過對(duì)payload進(jìn)行HTML編碼來繞過檢測(cè)，見圖2-3-20。

利用burpsuite對(duì)payload進(jìn)行實(shí)體編碼：

打開瀏覽器即可觸發(fā)，見圖2-3-21。

這里能觸發(fā)與瀏覽器渲染頁面的順序有關(guān)。我們的payload在標(biāo)簽屬性中，觸發(fā)事件前，瀏覽器已經(jīng)對(duì)payload進(jìn)行了一次解碼，即從實(shí)體編碼轉(zhuǎn)換成了常規(guī)數(shù)據(jù)。

如果對(duì)JavaScript的函數(shù)進(jìn)行過濾，如過濾了“eval（”這樣的字符組合，那么可以通過下面的方式進(jìn)行繞過：

正因?yàn)镴avaScript非常靈活，所以通過黑名單的方式對(duì)XSS攻擊進(jìn)行過濾是很困難的。

3．輸出在JavaScript變量中

通過閉合JavaScript語句，會(huì)使得我們的攻擊語句逃逸，這時(shí)有經(jīng)驗(yàn)的開發(fā)可能會(huì)對(duì)引號(hào)進(jìn)行編碼或者轉(zhuǎn)義，進(jìn)而防御XSS，但是配合一些特殊的場(chǎng)景依然可能形成XSS。例如，對(duì)于如下雙輸入的注入：

如果只過濾單引號(hào)而沒考慮“\”，那么我們可以轉(zhuǎn)義語句中的第二個(gè)單引號(hào)，使得第一個(gè)單引號(hào)和第三個(gè)單引號(hào)閉合，從而讓攻擊語句逃逸：

在XSS中也有類似的場(chǎng)景。例如，如下代碼：

輸入點(diǎn)和輸出點(diǎn)都有兩個(gè)，如果輸入引號(hào)，會(huì)被編碼成HTML實(shí)體字符，但是htmlentities函數(shù)并不會(huì)過濾“\”，所以我們可以通過“\”使得攻擊語句逃逸，見圖2-3-22。

在name處末尾輸入“\”，在addr參數(shù)處閉合前面的JavaScript語句，同時(shí)插入惡意代碼。進(jìn)一步可以用eval（window.name）引入惡意代碼或者使用JavaScript中的String.fromCharCode來避免使用引號(hào)等被過濾的字符。

再介紹幾個(gè)小技巧，見圖2-3-23，將payload藏在location.hash中，則URL中“＃”后的字符不會(huì)被發(fā)到服務(wù)器，所以不存在被服務(wù)器過濾的情況，見圖2-3-24。

在JavaScript中，反引號(hào)可以直接當(dāng)作字符串的邊界符。

4．CSP過濾及其繞過

我們引用https://developer.mozilla.org/zh-CN/docs/Web/HTTP/CSP的內(nèi)容來介紹CSP。

CSP（Content Security Policy，內(nèi)容安全策略）是一個(gè)額外的安全層，用于檢測(cè)并削弱某些特定類型的攻擊，包括跨站腳本（XSS）和數(shù)據(jù)注入攻擊等。無論是數(shù)據(jù)盜取、網(wǎng)站內(nèi)容污染還是散發(fā)惡意軟件，這些攻擊都是主要的手段。

CSP被設(shè)計(jì)成完全向后兼容。不支持CSP的瀏覽器也能與實(shí)現(xiàn)了CSP的服務(wù)器正常合作，反之亦然：不支持CSP的瀏覽器只會(huì)忽略它，正常運(yùn)行，默認(rèn)網(wǎng)頁內(nèi)容使用標(biāo)準(zhǔn)的同源策略。如果網(wǎng)站不提供CSP頭部，那么瀏覽器也使用標(biāo)準(zhǔn)的同源策略。

為了使CSP可用，我們需要配置網(wǎng)絡(luò)服務(wù)器返回Content-Security-Policy HTTP頭部（有時(shí)有X-Content-Security-Policy頭部的提法，那是舊版本，不需如此指定它）。除此之外，<meta>元素也可以被用來配置該策略。

從前面的一些過濾繞過也可以看出，XSS的防御絕非易事，CSP應(yīng)運(yùn)而生。CSP策略可以看作為了防御XSS，額外添加的一些瀏覽器渲染頁面、執(zhí)行JavaScript的規(guī)則。這個(gè)規(guī)則是在瀏覽器層執(zhí)行的，只需配置服務(wù)器返回Content-Security-Policy頭。例如：

這段代碼會(huì)規(guī)定，這個(gè)頁面引用的JavaScript文件只允許來自百度的子域，其他任何方式的JavaScript執(zhí)行都會(huì)被攔截，包括頁面中本身的script標(biāo)簽內(nèi)的代碼。如果引用了不可信域的JavaScript文件，則在瀏覽器的控制臺(tái)界面（按F12，打開console）會(huì)報(bào)錯(cuò)，見圖2-3-25。

CSP規(guī)則見表2-3-1。

表中的每個(gè)規(guī)則都對(duì)應(yīng)了瀏覽器中的某部分請(qǐng)求，如default-src指令定義了那些沒有被更精確指令指定的安全策略，可以理解為頁面中所有請(qǐng)求的一個(gè)默認(rèn)策略；script-src可以指定允許加載的JavaScript資源文件的源。其余規(guī)則的含義讀者可以自行學(xué)習(xí)，不再贅述。

在CSP規(guī)則的設(shè)置中，“*”可以作為通配符。例如，“*.baidu.com”指的是允許加載百度所有子域名的JavaScript資源文件；還支持指定具體協(xié)議和路徑，如“Content-Security-Policy：script-src http://*.baidu.com/js/”指定了具體的協(xié)議以及路徑。

除此之外，script-src還支持指定關(guān)鍵詞，常見的關(guān)鍵詞如下。

? none：禁止加載所有資源。

? self：允許加載同源的資源文件。

? unsafe-inline：允許在頁面內(nèi)直接執(zhí)行嵌入的JavaScript代碼。

? unsafe-eval：允許使用eval()等通過字符串創(chuàng)建代碼的方法。

所有關(guān)鍵詞都需要用單引號(hào)包裹。如果在某條CSP規(guī)則中有多個(gè)值，則用空格隔開；如果有多條指令，則用“；”隔開。比如：

5．常見的場(chǎng)景及其繞過

CSP規(guī)則眾多，所以這里只簡單舉例，其他相關(guān)規(guī)則及繞過方式讀者可以自行查閱相關(guān)資料。例如，對(duì)于“script-src'self'”，self對(duì)應(yīng)的CSP規(guī)則允許加載本地的文件，我們可以通過這個(gè)站點(diǎn)上可控的鏈接寫入惡意內(nèi)容，如文件上傳、JSONP接口。例如：

注意，如果是圖片上傳接口，即訪問上傳資源時(shí)返回的Content-Type是image/png之類的，則會(huì)被瀏覽器拒絕執(zhí)行。

假設(shè)上傳了一個(gè)a.xxxxx文件，通過URL的GET參數(shù)，把這個(gè)文件引入script標(biāo)簽的src屬性，此時(shí)返回的Content-type為text/plain，解析結(jié)果見圖2-3-26。

除此之外，我們可以利用JSONP命令進(jìn)行繞過。假設(shè)存在JSONP接口（見圖2-3-27），我們可以通過JSONP接口引入符合JavaScript語法的代碼，見圖2-3-28。

若該JSONP接口處于白名單域下，可以通過更改callback參數(shù)向頁面中注入惡意代碼，在觸發(fā)點(diǎn)頁面引入構(gòu)造好的鏈接，見圖2-3-29。

另一些常見的繞過方法如下：

當(dāng)傳出數(shù)據(jù)受限時(shí)，則可以利用JavaScript動(dòng)態(tài)生成link標(biāo)簽，將數(shù)據(jù)傳輸?shù)轿覀兊姆?wù)器，如通過GET參數(shù)帶出cookie：

還有就是利用頁面跳轉(zhuǎn)，包括a標(biāo)簽的跳轉(zhuǎn)、location變量賦值的跳轉(zhuǎn)，meta標(biāo)簽的跳轉(zhuǎn)等手法。比如，通過跳轉(zhuǎn)實(shí)現(xiàn)帶出數(shù)據(jù)：

2.3.4 XSS繞過案例

CTF中的XSS題目通常利用XSS bot從后臺(tái)模擬用戶訪問鏈接，進(jìn)而觸發(fā)答題者構(gòu)造的XSS，讀到出題者隱藏在bot瀏覽器中的flag。flag通常在bot瀏覽器的Cookie中，或者存在于只有bot的身份才可以訪問到的路徑。除了CTF題目，現(xiàn)實(shí)中也有相關(guān)XSS漏洞的存在，在第二個(gè)例子中，筆者將闡述一個(gè)自己曾經(jīng)挖到的XSS漏洞案例。

1．0CTF 2017 Complicated XSS

題目中存在兩個(gè)域名government.vip和admin.government.vip，見圖2-3-30。

題目提示：http://admin.government.vip：8000。測(cè)試后發(fā)現(xiàn)，我們可以在government.vip中輸入任意HTML讓BOT觸發(fā)，也就是可以讓bot在government.vip域執(zhí)行任意JavaScript代碼。經(jīng)過進(jìn)一步探測(cè)發(fā)現(xiàn)

<1>需要以管理員的身份向http://admin.government.vip：8000/upload接口上傳文件后，才能得到flag

<2>http://admin.government.vip：8000中存在一個(gè)XSS，用戶Cookie中的用戶名直接會(huì)被顯示在HTML內(nèi)容中，見圖2-3-31。

<3>http://admin.government.vip：8000/頁面存在過濾，刪除了很多函數(shù)，需要想辦法繞過才能把數(shù)據(jù)傳輸出去。過濾部分如下：

根據(jù)得到的信息可以梳理出思路，利用government.vip根域的XSS，將對(duì)admin子域攻擊的代碼寫入Cookie，設(shè)置Cookie有效的域?yàn)樗凶佑颍ㄋ凶佑蚓稍L問此Cookie）。設(shè)置完Cookie后，引導(dǎo)用戶訪問打印Cookie的頁面，使bot在admin子域觸發(fā)XSS，觸發(fā)后利用XSS在admin子域中新建一個(gè)iframe頁面，從而繞過頁面中函數(shù)的限制，并讀取管理員上傳頁面的HTML源碼，最后構(gòu)造上傳包利用XSS觸發(fā)上傳，獲得flag后發(fā)送給攻擊者。

首先，在根域觸發(fā)XSS的內(nèi)容：

將payload設(shè)置到Cookie中，然后引導(dǎo)bot訪問admin子域。惡意代碼的利用分兩次，第一次是讀取管理員上傳文件的HTML，讀到的上傳頁面見圖2-3-32。

讀到源碼后，修改payload構(gòu)造，利用JavaScript上傳文件的代碼，并且在上傳成功后，將頁面發(fā)送到自己的服務(wù)器。最后服務(wù)器收到帶著flag的請(qǐng)求，見圖2-3-33。flag就在上傳文件的響應(yīng)中。

2．某互聯(lián)網(wǎng)企業(yè)XSS

passport.example.com和wappass.example.com是該公司的通行證相關(guān)域，負(fù)責(zé)用戶的通行證相關(guān)任務(wù)。例如，攜帶令牌跳轉(zhuǎn)到其他子域進(jìn)行授權(quán)登錄，wappass子域負(fù)責(zé)二維碼登錄相關(guān)功能，可以在這個(gè)域進(jìn)行密碼更改等。

以前也挖掘到一些URL校驗(yàn)不嚴(yán)導(dǎo)致攜帶XXUSS跳轉(zhuǎn)到第三方域的安全問題。XXUSS曾是他們公司的唯一通行證（HTTP Only Cookie）。自從某次修復(fù)后，攜帶通行證跳轉(zhuǎn)的漏洞似乎徹底修復(fù)了，對(duì)于域名的校驗(yàn)極其嚴(yán)格，但存在利用的可能，如找到白名單子域的XSS或者可以帶出referer的頁面：

該公司跨域授權(quán)的URL是上面的URL，其中有多個(gè)參數(shù)：return type是指的授權(quán)類型可以是302跳轉(zhuǎn)，也可以是form表單；tpl參數(shù)是指本次跳轉(zhuǎn)到具體的什么服務(wù)，這個(gè)是服務(wù)名的縮寫；u參數(shù)則是這個(gè)服務(wù)對(duì)應(yīng)的授權(quán)URL。

經(jīng)過測(cè)試發(fā)現(xiàn)，302跳轉(zhuǎn)直接是帶著通行證302重定向到子域；form表單則返回一個(gè)自動(dòng)提交的表單且action為子域，參數(shù)為認(rèn)證參數(shù)。

這次的問題就出在表單跳轉(zhuǎn)處。上面提到對(duì)于u參數(shù)中的域名校驗(yàn)很嚴(yán)格，但是對(duì)于協(xié)議名校驗(yàn)并不嚴(yán)格。例如：

這樣的協(xié)議名是可以正確返回響應(yīng)頭的，卻是302跳轉(zhuǎn)過來的鏈接。如果不是合法的HTTP（S）協(xié)議，鏈接是不會(huì)被瀏覽器所接受的，所以類似：

這樣的URL是不可能彈框的，以上是所有的已知事情。

但是，在JavaScript中如果有這樣的URL，那么是可以攻擊的：

瀏覽器中，如果JavaScript調(diào)用了“javascript：”偽協(xié)議，那么后面的語句可以直接在當(dāng)前頁面當(dāng)作腳本執(zhí)行類似如下代碼也是可以的。

只要單擊它，就可以觸發(fā)對(duì)應(yīng)的腳本，然后似乎曾經(jīng)看到過一種攻擊payload：

這樣的payload依然可以執(zhí)行，因?yàn)椤?b>//”在JavaScript中代表的意思是注釋，通過后面的“%0a”換行符，使得攻擊語句跑到第2行，就避開了這個(gè)注釋符。似乎只要是JavaScript型的跳轉(zhuǎn)，就都可以觸發(fā)JavaScript偽協(xié)議？form表單是否也可以看作一種攜帶著數(shù)據(jù)進(jìn)行JavaScript跳轉(zhuǎn)的方式？

測(cè)試代碼如下，結(jié)果見圖2-3-34。

結(jié)果如預(yù)期般彈窗了。也就是說，只要是自動(dòng)提交的表單，如果action中的協(xié)議和URL后半段可控，就能得到一個(gè)XSS。這時(shí)，結(jié)合前的修復(fù)不算完全的漏洞：“JavaScript型跳轉(zhuǎn)，域名不可控，但是協(xié)議和URL可控”，那么就得到了一個(gè)該公司登錄域的XSS，見圖2-3-35。

這樣便通過了URL校驗(yàn)，見圖2-3-36，成功執(zhí)行了我們的XSS代碼。

此時(shí)，我們得到了一個(gè)該企業(yè)登錄域的XSS并可以無視瀏覽器的過濾、通殺各種瀏覽器，前面提到該企業(yè)的二維碼登錄功能在此域?qū)崿F(xiàn)。那么我們得到了這個(gè)XSS，就可以對(duì)用戶進(jìn)行CSRF攻擊，讓用戶在訪問我們的惡意頁面的時(shí)候相當(dāng)于完成了對(duì)登錄二維碼進(jìn)行掃描和確認(rèn)的動(dòng)作。

誘導(dǎo)用戶訪問的頁面內(nèi)容，代碼如下：

attack.php內(nèi)容如下：

上述代碼是最終利用的payload，當(dāng)用戶訪問此網(wǎng)頁時(shí)會(huì)觸發(fā)XSS，并且通過CSRF的攻擊手法，自動(dòng)化對(duì)攻擊者打開的一個(gè)二維碼登錄頁面進(jìn)行授權(quán)。

授權(quán)完畢，攻擊者就可以在瀏覽器登錄受害者的賬號(hào)，進(jìn)而以對(duì)方身份瀏覽各種業(yè)務(wù)。