前言
以往也了解過同源策略、跨域等方面的知識，但都是零零散散的，也沒深入思考相互之間的聯(lián)系，本文旨在通過將相關(guān)的知識點串聯(lián)起來，系統(tǒng)性的歸納總結(jié)。
一、同源策略是什么？
同源策略限制了從同一個源加載的文檔或腳本如何與來自另外一個源的資源進行交互。這是一個用于隔離潛在惡意文件的重要安全機制。
1.1 怎么才算是同源？
同時滿足以下3個條件：
- 協(xié)議
http 和 https 會被算作不同 - 域名
注意二級域名和主域名會被算作不同 - 端口
1.2 同源策略具體限制了什么
- 無法讀取非同源網(wǎng)頁的 Cookie、LocalStorage、IndexedDB
- 無法接觸非同源網(wǎng)頁的 DOM
- 向非同源地址發(fā)送 AJAX 請求，瀏覽器會攔截請求的響應(yīng)。
二、為什么要有同源策略？
試想一下，如果沒有同源策略，會發(fā)生什么？
隨便舉幾個例子，如果沒有 1.2 中的種種限制，下面的情況很容易發(fā)生：
- 嵌套第三方網(wǎng)頁，并修改第三方網(wǎng)頁的 DOM 結(jié)構(gòu)
- xss攻擊難度降低
在有同源策略之后，需要向被攻擊站點注入腳本才能獲取 LocalStorage、Cookie 中的信息，如果沒有同源限制，只要被攻擊者訪問過其他站點，再訪問攻擊者的站點，攻擊者站點中的腳本可直接獲取被攻擊者之前訪問過的站點的信息了，都不需要注入腳本了。 - csrf 攻擊
既然能輕易獲取到 cookie 等信息，可以直接通過 AJAX 發(fā)起偽造請求了。
通過以上 3 個例子可以看出，安全隱患太嚴重了，必須要引入同源策略來規(guī)避風(fēng)險。
三、同源策略帶來的問題
事物具有兩面性，同源策略降低了安全風(fēng)險的同時，也帶來了很多不便。
再舉幾個例子：
- 前后端分離時期的 AJAX 跨域請求
- 新站點嵌套了部分舊站點頁面，需要通信
不同源的站點或地址之間的通信被阻斷，即常見的跨域問題。
四、如何解決跨域
首先說明一點，跨域不僅僅包括 ajax 請求這一種情況，不同源的網(wǎng)頁之間也有通信的需要。
(一) AJAX
4.1 JSONP
原理：
-
<script>標(biāo)簽的 src 屬性是不受同源限制的(<img>標(biāo)簽也是如此) - 先提前定義好一個回調(diào)函數(shù)
function foo(data) {
console.log(data);
}
- 將 foo 當(dāng)做請求參數(shù)傳遞到服務(wù)器
- 服務(wù)器解析參數(shù)，獲取 foo
- 服務(wù)器從數(shù)據(jù)庫獲取業(yè)務(wù)數(shù)據(jù) data
- 服務(wù)器返回響應(yīng) foo(data) , 即把 data 當(dāng)做參數(shù)
- 因為是通過 <script> 請求的，所以得到的響應(yīng)就相當(dāng)于請求回來一段 js 腳本，然后執(zhí)行。
缺點：只支持 GET 請求。
4.2 CORS
CORS 全稱是跨域資源共享（Cross-origin resource sharing）
詳細請查看我的另一篇文章 CORS 學(xué)習(xí)筆記
4.3 Access-Control-Allow-Origin 白名單
其實就是 CORS 的具體實現(xiàn)。
服務(wù)端設(shè)置 header 頭
Access-Control-Allow-Origin: *;
一般開發(fā)平臺提供的 API 都是這樣做的。但是對于不想開放的平臺，使用 '*' 存在較大的安全風(fēng)險，建議使用精確的域名來控制。
額外解答：為什么 Access-Control-Allow-Credentials: true; 時，不能設(shè)置 Access-Control-Allow-Origin 的值為 *。
我的思考結(jié)論：Access-Control-Allow-Credentials 字段用來控制對帶憑證的請求，服務(wù)器是否返回響應(yīng)，Access-Control-Allow-Origin 字段用來控制請求的資源是否允許訪問，我們先假設(shè)允許問題中的設(shè)置，會出現(xiàn)什么情況呢？會出現(xiàn)：一個攜帶憑證的跨域請求可以得到請求結(jié)果，猛一看好像沒啥問題啊，我們平時開發(fā)不就為了實現(xiàn)跨域請求嘛，可是如果這個請求是偽造的呢？即 csrf 攻擊，因為 Access-Control-Allow-Origin: * 所以同源策略中對于不同源 AJAX 請求的限制沒了，這很容易造成安全問題。這里細心的同學(xué)會發(fā)現(xiàn)，那和 Access-Control-Allow-Credentials: true; 有什么關(guān)系呢？我的理解是，為什么請求需要帶憑證呢，或者說什么樣的請求需要帶憑證？這樣想就會明白，肯定是重要的資源，有安全要求，不想輕易被訪問，所以服務(wù)器會對憑證進行校驗，校驗通過后才會返回響應(yīng)的，因為像是開發(fā)平臺這樣的站點就是讓別人請求的，所以設(shè)置Access-Control-Allow-Origin: *不會有問題，核心思想就是“重要的資源，不應(yīng)該允許任意站點請求”，這個問題解釋完了。
4.4 WebSocket
webSocket 是不受同源限制的。
4.5 代理服務(wù)器
瀏覽器請求同源服務(wù)器，服務(wù)器負責(zé)請求外部服務(wù)器。
舉例：nginx 反向代理
(二) Cookie
4.6 設(shè)置 cookie 的 domain 屬性
cookie 有個 domain 屬性，用來設(shè)置 cookie 的作用域(結(jié)合 cookie 的另一個屬性 path 使用)。
如果子域名 a.mozilla.org 和 b.mozilla.org 想要共享一段 cookie ，只要將 cookie 的 domain 屬性設(shè)置成共同的父域名 domain=mozilla.org 即可。
4.7 document.domain
這里阮一峰的方法是在兩個子站點中通過腳本設(shè)置 document.domain='mozilla.org'。
缺點：
- 不方便，因為需要協(xié)作的站點都要執(zhí)行上述腳本才行，原因：
document.domain = xxx會導(dǎo)致端口號被重置為null。 - 不適合只需要共享部分 cookie 的需求
優(yōu)點：document.domain 可以達到讓父子域或者多個子域變成同源，作用不局限于 cookie 的共享。
(三) Iframe 跨窗口通信
4.8 片段識別符
指 url 中 # 后面的部分, 把需要傳遞的數(shù)據(jù)放到片段識別符中。
父窗口改變子窗口的片段標(biāo)識符：
let src = originURL + '#' + data;
document.getElementById('childIFrame').src = src;
子窗口改變父窗口的片段標(biāo)識符：
parent.location.href = target + '#' + hash;
監(jiān)聽 hash 的變化
window.onhashchange = function () {
let msg = window.location.hash;
}
缺點：
- url 長度有限，不能傳遞太多的數(shù)據(jù)
- 不是標(biāo)準規(guī)范
4.9 window.postMessage()
跨文檔通信 API（Cross-document messaging）為 window 對象提供了postMessage()，允許跨窗口通信，無論是否同源。
語法：otherWindow.postMessage(message, targetOrigin, [transfer]);
父窗口向子窗口發(fā)送消息：
let pop = window.open('http://bbb.com', 'title');
pop.postMessage('hello world', 'http://bbb.com');
子窗口向父窗口發(fā)送消息：
window.opener.postMessage('I received', 'http://aaa.com');
監(jiān)聽消息：
window.addEventListener('message', function(e) {
console.log(e.data);
})
- event.source：發(fā)送消息的窗口
- event.origin: 消息發(fā)向的網(wǎng)址
- event.data: 消息內(nèi)容
安全
- 不希望從其他網(wǎng)站接收 message，請不要為 message 添加事件監(jiān)聽。
- 始終使用
origin和source屬性驗證發(fā)件人的身份。 - 向其他窗口發(fā)送數(shù)據(jù)時，指定精確的
origin。
參考
阮一峰：同源策略
阮一峰：CORS
會編程的銀豬：同源策略和跨域請求研究
MDN：Same-origin_policy
MDN：postMessage
MDN：CORSNotSupportingCredentials
MDN：Access-Control-Allow-Credentials
