前端也須要了解的 JSONP 安全

什麼是 JSONP（JSON with Padding）？

What? 你還不知道 JSONP 是什麼？趕忙去補補吧，我就很少講了。 補個百度百科連接先，baike.baidu.com/item/jsonp/…

會有哪些安全隱患？怎麼防範？

咱們假設有這樣一個場景一
我登陸了 www.qq.com，QQ 爲了給第三方提供服務，可能會有這樣的 jsonp 接口，www.qq.com/getUserInfo?callback=action，那我就能夠本身構造一個惡意頁面，請求這個 jsonp 接口，放在網絡上，收集 qq 用戶的信息了。要是 jsonp 接口還涉及了一些敏感操做或者信息，就更嗨皮了~好比登錄啊，刪除啊等操做。不過國內不少後端開發並不重視此問題，忽然想起來老東家的後端開發爲了加速開發，寫了個通用的函數，只要能 GET 訪問的接口均可以 jsonp 訪問。Emmm...

對於第一種狀況，首先要驗證 JSONP 調用的來源（Referer），這種方案利用了 js 資源加載時會發送 Referer 的特性，服務端判斷 Referer 是否是白名單便可。
提及來容易，但實際還會由於過濾的正則不嚴謹致使繞過，好比只驗證了是否存在 www.qq.com 關鍵字，那我能夠構造 www.qq.com.domain.com 來進行攻擊。又好比不少開發會容許空 Referer，而跨協議調用 js 是不發送 Referer 的，可謂是千里之堤潰於蟻穴~跨協議調用 js 的一個例子： <iframe src="javascript:'<script src=http://attack.com/jsonp></script>'"></iframe> 代碼裏使用 iframe 調用 javascript 僞協議，來發送空 Referer 的 js 請求。
因此空 Referer 仍是要禁止滴。
另外就是部署隨機 Token 來防護了，每一次請求都帶上 token 值，token 值字母加數字長一點最好了，否則有被暴力破解的可能。

接下來是場景二
不嚴謹的 content-type 致使的 XSS 漏洞 想象一下 jsonp 就是你請求 http://youdomain.com?callback=douniwan, 而後返回 douniwan({ data }),那假如請求 http://youdomain.com?callback=<script>alert(1)</script> 不就返回 <script>alert(1)</script>({ data }) 了嗎，若是沒有嚴格定義好 Content-Type（ Content-Type: application/json ），再加上沒有過濾 callback 參數，直接當 html 解析了，就是一個赤裸裸的 XSS 了。 Content-Type 設置成 application/javascript 在 IE 等瀏覽器下同樣能夠解析成 HTML 致使 XSS 漏洞。因此要嚴格定義成 application/json。不過即便這樣，在五花八門的瀏覽器面前，也會有個別特殊的，好比在 IE6/7 下面，請求的 URL 文件後面加一個 /x.html 就能夠解析成 html。

防護這種狀況首先要嚴格定義 Content-Type: application/json，而後嚴格過濾 callback 後的參數而且限制長度。
有時候咱們會在某些框架的內置 jsonp 函數返回內容裏看到這樣的開頭：/**/, 好比 Express 框架內置的 jsonp 函數會這樣返回：

/**/ typeof func === 'function' && func({"data":"hello"});
複製代碼

這是爲何呢？其實這都是有歷史緣由的，2011 年的時候出過一個經過 mhtml 協議解析跨域的漏洞：MHTML Mime-Formatted Request Vulnerability (CVE-2011-0096)，當時也是影響了一堆國際廠商，想詳細瞭解的能夠戳這裏，technet.microsoft.com/library/sec…
防護這個就是在前面加上 /**/ 或者多個換行符就能必定程度預防其餘文件格式的輸出了。

接下來是場景三
假如個人網站用了第三方的服務，而對方提供的只有 jsonp 接口，萬一對方的服務器被黑了，返回了一串惡意代碼，那不是城門失火，殃及池魚了嗎？
請記住一句話，全部的第三方都是不可徹底信任的。
防護的話，首先，考慮一下，前端能作什麼防護措施？
iframe？好像能夠，搜了下，網上已經有人作了嘗試了，詳細能夠看這裏 github.com/aui/jsonp-s…
還有什麼方法呢？前端好像沒什麼能夠檢測返回的 js 內容的函數了，好像沒什麼能夠玩的了。
那換個思路，服務端轉發呢，既然前端不能檢測第三方的 jsonp 內容，那我用本身的服務端去檢測第三方的 jsonp 內容是否合法，再返回結果不就好了。

最後

繞來繞去，總感受用的不太爽，可能正是因爲 jsonp 的種種缺陷，才一直沒有被瀏覽器標準採納吧。