瀏覽器中有兩個安全機制,一個瀏覽器沙盒(Sandbox),另外一個就是同源策略(Same Origin Policy,簡稱SOP) ,下面介紹同源策略。同源是指同協議
、同域名
、同端口
,必須三同,缺一不可。下面列舉了一些例子,爲方便讀者瞭解哪些是屬於同源,下面列舉一些案例:
javascript
根據這個策略,a.com域名下的JavaScript沒法跨域操做b.com域名下的對象。跨域的安全限制都是對瀏覽器端來講的,服務器端是不存在跨域安全限制的。以下流程圖:
流程圖1.html
流程圖2.前端
不一樣源也意味着不能通訊,由於同源策略認爲其餘任何站點的資源內容都是不安全的。這個限制有必定的道理,咱們來想象一個場景,假設攻擊者利用Iframe
標籤,把真正的銀行登錄頁面嵌套在他的頁面上,那麼當用戶在這個嵌套的頁面上登錄時,該頁面就能夠經過JavaScript讀取到用戶表單中的內容,意味着用戶就泄露了登錄信息。java
瀏覽器使用了同源策略以後,好處
是能確保用戶正在查看的頁面確實是來自於正在瀏覽的域,然而有好就會有壞,壞處
是一些業務就是須要進行跨域操做,同源策略顯然就阻擋了業務需求。好比如今IT公司都發展得大,(假設的案例)阿里公司有好幾個事業部,淘寶、天貓、支付寶等獨立的事業部,你在登錄支付寶頁面的時候,你跳轉到支付寶的我的中心頁面時,支付寶就會跨域去請求你登錄過的淘寶站的接口來回傳你的我的信息。web
在這種情景下,開發者怎麼跨域的?其實方法仍是有不少的,好比JSONP就是其中一種。下面咱們介紹JSONP跨域請求。json
爲了便於客戶端使用跨站的數據,開發的過程當中逐漸造成了一種非正式傳輸協議。人們把它稱做JSONP,該協議的一個要點就是容許用戶傳遞一個callback參數給服務端,而後服務端返回數據時會將這個callback參數做爲函數名來包裹住JSON數據,這樣客戶端就能夠隨意定製本身的函數來自動處理返回數據了。後端
JSONP 跨域請求的原理,能夠參考下面的文章,這位大佬從前端開發的角度把開發流程都講清楚了, 我就不在敘述了。
https://www.cnblogs.com/chiangchou/p/jsonp.htmlapi
隨着跨域技術帶來了便利,一樣的,也帶來了安全風險。跨域
https://space.bilibili.com/9996xxx1
callback=
很明顯了,如今所在域名是space.bilibili.com
,可是卻跨域請求了api.bilibili.com
的數據瀏覽器
https://api.bilibili.com/x/space/myinfo?jsonp=jsonp&callback=__jp0
,看到URL的GET參數裏面並無攜帶token,那麼有如下兩種方式來測試是否存在JOSONP劫持。
正常重放如下數據包,看到我的信息正常返回。
修改Referer
Referer: https://space.abilibili.com/9996xxx1 ,將space.bilibili.com改爲space.abilibili.com
,發現返回信息沒有我的信息,意味着不存在JSONP劫持。
製做一個playload:
<html> <meta content="text/html; charset=utf-8" http-equiv="Content-Type" /> <script type="text/javascript"> function __jp0(result) { console.log(result); } </script> <script type="text/javascript" src="https://api.bilibili.com/x/space/myinfo?jsonp=jsonp&callback=__jp0"></script> </html>
放在一個web站點,使用已經登錄B站的瀏覽器打開這個連接。若是控制檯(Console)沒有輸出我的信息,也意味着不存在JSONP劫持。
利用上相同:
兩個不一樣:
JSONP劫持屬於CSRF( Cross-site request forgery 跨站請求僞造)的攻擊範疇,因此解決的方法和解決CSRF的方法同樣。 一、驗證 HTTP Referer 頭信息; 二、在請求中添加Token,並在後端進行驗證;