瀏覽器同源策略理解

1、背景說明

昨天領導要求給研發提個單，要求加上X-Frame-Options頭，和他說這個頭部以前客戶已經要求加過了，順帶說了這東西就是爲了防範攻擊者經過iframe等引用頁面進行點擊劫持用的。

後來他又詢問說經過iframe引入後是否是用戶在iframe中的輸入及操做的響應結果是否iframe外層都能經過js直接或取到，由於從消息流向來講，消息確定是先到達瀏覽器再傳到web頁面再傳到web頁面內的iframe；而後他又從另外一個角度問，iframe內外層是不一樣的網站，擴展到網絡上，是否是A站的js也能夠請求B站的接口？若是是，那這叫什麼同源？

對於前一個問題，沒仔細探究過只好回答說你按客戶端編程的思路來講外層確實能夠獲取流向內層的數據，我只能說個人經驗和我看的書都告訴我因爲同源策略外層不能訪問內層的數據內層也不能訪問外層的數據，你要問原理我就說不上來。對於後一個問題，後來想了想這就是以前討論過的跨域請的問題了，服務端經過瀏覽器提交的Origin頭決定是否進行響應，瀏覽器經過服務端返回的Access-Control-Allow-Origin頭決定是否進行解析。

 

2、同源策略

2.1 同源的含義

「同源」這個詞最開始在哪看到已經不太記得了，但這個詞從一開始就以爲很好理解：同IP同端口就是同源，反之就不一樣源。

如今看網上說，同協議同域名同端口就是同源。因爲CDN等機制用域名訪問一個網站並不必定老是一個IP，因此域名+端口這個說法確實更嚴謹一些。至於同域名/同IP難道還有不一樣協議這個問題，就要說遠一些，最近本身常常說滲透測試的第一步是威脅建模所謂威脅建模就是看系統開放了什麼端口各端口下面使用了哪些協議，上週也和一個朋友這樣說她忽然問一個端口下會有多套不一樣的協議嗎而後又接着本身答這種狀況應該比較少吧。回頭仔細想本身一個端口下可有多套協議的認知，大概來源於公司產品的私有協議端口既可傳輸控制請求也可傳輸視頻流數據；從原理上而言，一個端口實現多套協議，重點在於數據包協議類型判斷上，只要判斷接收到的數據包類型而後轉發到相應的進程上處理就能夠了；從實踐上看，SSLH等就能夠實現多套協議只開一個端口。即總的而言，首先一個端口多套協議是有可能的----但確實這種場景比較少；而後我並不肯定瀏覽器是否會將同域名/IP同端口不一樣協議視爲不一樣源，只能說直覺上同協議也是一項標準確實更準確一些。

 

2.2 同源策略的含義

如前面所說，總的而言「同源」仍是比較好理解的，但同源策略具體是什麼呢？或者說同源又怎樣不一樣源又怎樣？總的而言有如下三點限制：

一是來自一個源的js只能讀寫本身源的存儲不能讀寫其餘源的存儲，存儲包括Cookie、Session Storage、Local Storage、Cache、Indexed DB等。

二是來自一個源的js只能讀寫本身源的DOM樹不能讀取其餘源的DOM樹。即若是開始討論，iframe內外層不一樣源就不能相互操做，外層想獲取內層的內容只能使用點擊劫持配合；實現原理亦如前所述未知。

三是通常而言來自一個源的js只能向本身源的接口發送請求不能向其餘源的接口發送請求。固然其實本質是，一方面瀏覽器發現一個源的js向其餘源的接口發送請求時會自動帶上Origin頭標識來自的源，讓服務器能經過Origin判斷要不要嚮應；另外一方面，瀏覽器在接收到響應後若是沒有發現Access-Control-Allow-Origin容許發送請求的域進行請求那也不容許解析。本身以前也抱怨過，又不是服務器不響應服務器響應了不瀏覽器不（容許js）解析是否是沒什麼意義的畫蛇添足；如今看來，經過本身寫python等方法也確實能請求其餘服務器並解析其結果，瀏覽器沒有Access-Control-Allow-Origin容許不解析一是說維護了本身同源策略的思想二是說至少能夠保證不會在本身身上出現A域可隨便探測B域的狀況，因此也不能說徹底沒用。

四是來自一個源的js不能隨意操做瀏覽器以外的資源。好比打開命令提示符、執行系統命令等等。假若你訪問一個網站該網站的js能夠直接調用系統命令給你電腦進行添加用戶等操做，那問題就大了。

 

2.3 同源策略說明

不是說來自A域的js不能操做B域嗎，那咱們常常經過<script>標籤從別的網站引入js文件而後用來操做本身網站的內容，這不是明顯不符合同源策略嗎？

對於這個問題，我的是這樣考慮，從其餘網站引入的js文件並無直接操做本網站的內容，而是須要本網站上寫js調用js文件中的函數引入的js文件才能起做用；因此應該理解爲仍是本站的js操做本站的內容，至少是本站的js主動要求其餘站的js處理本站的內容。

 

參考：

http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html