淺聊同源策略的一些基礎

在學會了HTTP資料包的攔截和修改之後，你可能觀察到了不少網站的一些介面資訊。

而瀏覽器為了保證使用者隱私以及其它因素考慮，對於網路介面的呼叫有一層屏障，這層屏障稱為同源策略。那麼今天我們就來學習這個同源策略，希望能提升大家對於介面的測試和利用水平。

首先說說為什麼存在同源策略，我們知道JavaScript可以操作html，可以發出請求，也可以用iframe載入別的網站。

那麼試想一下，你登陸了一個購物網站比如京東，接著去訪問了pockr社群。如果pockr社群利用JavaScript給京東的收貨地址url發起了請求，從原則上講，這個請求不會成功，否則你的隱私就洩露了。那麼控制這個請求的成功與否，就叫同源策略。

同源策略的規定可以概括成：不同域的客戶端指令碼在沒明確授權的情況下，不能讀寫對方的資源，主要有三要素：協議相同、域名相同、埠相同。

我以https://pockr.org/activity 這個url給大家舉個例子，

參照URL https://pockr.org/activity (https://www.pockr.org/activity)對比URL 是否同域：

原因

https://www.pockr.org/activity 對比  (https://pockr.org/activity)  答案：否

www.pockr.org是二級域名,pockr.org是根域名

http://www.pockr.org/activity  對比 https://pockr.org/activity) 答案：否 

http是80埠,https是443埠,埠號不同

https://pockr.org/activity 對比 https://pockr.org/bug-environment 答案：是 

協議相同,域名相同，埠相同，是同源，只是路徑不path部分不同而已

那麼跨源會發生什麼呢？我給大家舉個例子：

現在我們訪問 https://pockr.org/

接著我們用JavaScript指令碼請求一下 https://www.pockr.org 這個不同源的地址。

(瀏覽器控制檯植入JavaScript)

可以看到瀏覽器控制檯報了一個錯誤,（原因：CORS 頭缺少 'Access-Control-Allow-Origin'）,提示非常明顯

我們用抓一下資料包看看，首先給大家介紹一下,破殼用的是https協議,直接用burp抓包的話會提示不安全,這是因為burp作為代理,替換了破殼的ssl證照,這時候只需要訪問http://burp , 下載burp的證照然後匯入瀏覽器就可以成功抓取https的資料了

那麼我們再來抓一次這個跨域請求觀察一下。首先可以看出請求是往外發的，因為burp攔截到對外傳送的資料包

同時我們看下返回內容，那麼我們根據報錯,在返回資料包中加上一個錯誤提示裡缺失的http頭會有什麼效果呢?

可以看到報錯消失了,請求得到了響應，那麼就是說瀏覽器攔截了跨源請求的返回結果

這個例子說明了：雖然有同源策略在，但是是可以協商的。只要被請求的一方用某種方式允許了你訪問，就可以突破同源策略的限制。

接下來我們看一些業務上常見的允許跨源訪問的例子

1.jsonp

jsonp的本質是跨源的對方給你一段JavaScript指令碼讓你執行,而script標籤的src屬性是允許跨源的,所以達到了跨源的目的

給大家演示一下

可以看到，127.0.0.1:9999這個源下面的html 建立了一個script標籤,利用src屬性,通過url傳遞資料給test.shuimugan.net，test.shuimugan.net則返回了一個JavaScript指令碼給127.0.0.1:9999執行,兩個源之間達到了資料互動

2.CORS

CORS的原理就是剛剛我們操作修改HTTP響應的過程，是被請求的服務端獲取到發出請求方的請求後，決定給響應頭加上了Access-Control-Allow-Origin相關的資訊，瀏覽器就會對響應放行，讓請求方拿到資料。

3.WebSocket

WebSocket是一種通訊協議，使用ws://（非加密）和wss://（加密）作為協議字首。該協議不實行同源政策，只要伺服器支援，就可以通過它進行跨源通訊。

可以看到我們127.0.0.1:9999毫無報錯就可以通過ws協議給test.shuimugan.net:8081發資訊

那麼常見業務的跨源場景就講解到這裡啦~