同源策略 瀏覽器中有兩個安全機制，一個瀏覽器沙盒（Sandbox），另一個就是同源策略(Same Origin Policy，簡稱SOP) ，下麵介紹同源策略。同源是指 、`同功能變數名稱 同埠`，必須三同，缺一不可。下麵列舉了一些例子，為方便讀者瞭解哪些是屬於同源，下麵列舉一些案例： 根據這個策略，a. ...
同源策略
瀏覽器中有兩個安全機制，一個瀏覽器沙盒（Sandbox），另一個就是同源策略(Same Origin Policy，簡稱SOP) ，下麵介紹同源策略。同源是指同協議、同功能變數名稱、同埠，必須三同，缺一不可。下麵列舉了一些例子，為方便讀者瞭解哪些是屬於同源，下麵列舉一些案例：
根據這個策略，a.com功能變數名稱下的JavaScript無法跨域操作b.com功能變數名稱下的對象。跨域的安全限制都是對瀏覽器端來說的，伺服器端是不存在跨域安全限制的。如下流程圖：
流程圖1.
流程圖2.
不同源也意味著不能通信，因為同源策略認為其他任何站點的資源內容都是不安全的。這個限制有一定的道理，我們來想象一個場景，假設攻擊者利用Iframe標簽，把真正的銀行登陸頁面嵌套在他的頁面上，那麼當用戶在這個嵌套的頁面上登陸時，該頁面就可以通過JavaScript讀取到用戶表單中的內容，意味著用戶就泄露了登陸信息。
瀏覽器使用了同源策略之後，好處是能確保用戶正在查看的頁面確實是來自於正在瀏覽的域，然而有好就會有壞，壞處是一些業務就是需要進行跨域操作，同源策略顯然就阻擋了業務需求。比如現在IT公司都發展得大，（假設的案例）阿裡公司有好幾個事業部，淘寶、天貓、支付寶等獨立的事業部，你在登陸支付寶頁面的時候，你跳轉到支付寶的個人中心頁面時，支付寶就會跨域去請求你登陸過的淘寶站的介面來回傳你的個人信息。
在這種情景下，你可以思考一下開發者怎麼做到跨域的？其實解決方法還是有很多的，比如JSONP就是其中一種。下麵我們就介紹JSONP跨域請求。
JSONP原理
為了便於客戶端使用跨站的數據，開發的過程中逐漸形成了一種非正式傳輸協議。人們把它稱作JSONP，該協議的一個要點就是允許用戶傳遞一個callback參數給服務端，然後服務端返回數據時會將這個callback參數作為函數名來包裹住JSON數據，這樣客戶端就可以隨意定製自己的函數來自動處理返回數據了。
JSONP 跨域請求的原理，可以參考下麵的文章，這位大佬從前端開發的角度把開發流程都講清楚了， 我就不在敘述了。
https://www.cnblogs.com/chiangchou/p/jsonp.html
隨著跨域技術帶來了便利，同樣的，也帶來了安全風險。
觀察B站的JSONP跨域請求流程
-
- 登陸B站之後，進入B站的個人中心頁面：
https://space.bilibili.com/9996xxx1
- 登陸B站之後，進入B站的個人中心頁面：
-
- 打開F12調試工具，查看是否有跨站請求，通過查看url 是否有
callback=
- 打開F12調試工具，查看是否有跨站請求，通過查看url 是否有
很明顯了，現在所在功能變數名稱是space.bilibili.com，但是卻跨域請求了api.bilibili.com的數據
-
- 查看前端源碼，發現確實是做了jsonp
- 查看前端源碼，發現確實是做了jsonp
測試是否存在JSONP劫持
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的相同與不同
利用上相同：
- 需要用戶點擊惡意鏈接
- 用戶必須登陸該站點，在本地存儲了Cookie
兩個不同：
- 必須找到跨站請求資源的介面來實施攻擊
- CSRF只管發送http請求，但是Jsonp Hijacking的目的是獲取敏感數據
JSONP劫持的防禦方法
JSONP劫持屬於CSRF（ Cross-site request forgery 跨站請求偽造）的攻擊範疇，所以解決的方法和解決CSRF的方法一樣。
1、驗證 HTTP Referer 頭信息；
2、在請求中添加Token，併在後端進行驗證；
