本文轉載:http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html javascript
瀏覽器安全的基石是"同源政策"(same-origin policy)。不少開發者都知道這一點,但瞭解得不全面。html
本文詳細介紹"同源政策"的各個方面,以及如何規避它。java
1995年,同源政策由 Netscape 公司引入瀏覽器。目前,全部瀏覽器都實行這個政策。web
最初,它的含義是指,A網頁設置的 Cookie,B網頁不能打開,除非這兩個網頁"同源"。所謂"同源"指的是"三個相同"。跨域
協議相同瀏覽器
域名相同安全
端口相同服務器
舉例來講,http://www.example.com/dir/page.html
這個網址,協議是http://
,域名是www.example.com
,端口是80
(默認端口能夠省略)。它的同源狀況以下。websocket
http://www.example.com/dir2/other.html
:同源cookie
http://example.com/dir/other.html
:不一樣源(域名不一樣)
http://v2.www.example.com/dir/other.html
:不一樣源(域名不一樣)
http://www.example.com:81/dir/other.html
:不一樣源(端口不一樣)
同源政策的目的,是爲了保證用戶信息的安全,防止惡意的網站竊取數據。
設想這樣一種狀況:A網站是一家銀行,用戶登陸之後,又去瀏覽其餘網站。若是其餘網站能夠讀取A網站的 Cookie,會發生什麼?
很顯然,若是 Cookie 包含隱私(好比存款總額),這些信息就會泄漏。更可怕的是,Cookie 每每用來保存用戶的登陸狀態,若是用戶沒有退出登陸,其餘網站就能夠冒充用戶,隨心所欲。由於瀏覽器同時還規定,提交表單不受同源政策的限制。
因而可知,"同源政策"是必需的,不然 Cookie 能夠共享,互聯網就毫無安全可言了。
隨着互聯網的發展,"同源政策"愈來愈嚴格。目前,若是非同源,共有三種行爲受到限制。
(1) Cookie、LocalStorage 和 IndexDB 沒法讀取。
(2) DOM 沒法得到。
(3) AJAX 請求不能發送。
雖然這些限制是必要的,可是有時很不方便,合理的用途也受到影響。下面,我將詳細介紹,如何規避上面三種限制。
Cookie 是服務器寫入瀏覽器的一小段信息,只有同源的網頁才能共享。可是,兩個網頁一級域名相同,只是二級域名不一樣,瀏覽器容許經過設置document.domain
共享 Cookie。
舉例來講,A網頁是http://w1.example.com/a.html
,B網頁是http://w2.example.com/b.html
,那麼只要設置相同的document.domain
,兩個網頁就能夠共享Cookie。
document.domain = 'example.com';
如今,A網頁經過腳本設置一個 Cookie。
document.cookie = "test1=hello";
B網頁就能夠讀到這個 Cookie。
var allCookie = document.cookie;
注意,這種方法只適用於 Cookie 和 iframe 窗口,LocalStorage 和 IndexDB 沒法經過這種方法,規避同源政策,而要使用下文介紹的PostMessage API。
另外,服務器也能夠在設置Cookie的時候,指定Cookie的所屬域名爲一級域名,好比.example.com
。
Set-Cookie: key=value; domain=.example.com; path=/
這樣的話,二級域名和三級域名不用作任何設置,均可以讀取這個Cookie。
若是兩個網頁不一樣源,就沒法拿到對方的DOM。典型的例子是iframe
窗口和window.open
方法打開的窗口,它們與父窗口沒法通訊。
好比,父窗口運行下面的命令,若是iframe
窗口不是同源,就會報錯。
document.getElementById("myIFrame").contentWindow.document// Uncaught DOMException: Blocked a frame from accessing a cross-origin frame.
上面命令中,父窗口想獲取子窗口的DOM,由於跨源致使報錯。
反之亦然,子窗口獲取主窗口的DOM也會報錯。
window.parent.document.body// 報錯
若是兩個窗口一級域名相同,只是二級域名不一樣,那麼設置上一節介紹的document.domain
屬性,就能夠規避同源政策,拿到DOM。
對於徹底不一樣源的網站,目前有三種方法,能夠解決跨域窗口的通訊問題。
片斷識別符(fragment identifier)
window.name
跨文檔通訊API(Cross-document messaging)
片斷標識符(fragment identifier)指的是,URL的#
號後面的部分,好比http://example.com/x.html#fragment
的#fragment
。若是隻是改變片斷標識符,頁面不會從新刷新。
父窗口能夠把信息,寫入子窗口的片斷標識符。
var src = originURL + '#' + data;document.getElementById('myIFrame').src = src;
子窗口經過監聽hashchange
事件獲得通知。
window.onhashchange = checkMessage;function checkMessage() { var message = window.location.hash; // ...}
一樣的,子窗口也能夠改變父窗口的片斷標識符。
parent.location.href= target + "#" + hash;
瀏覽器窗口有window.name
屬性。這個屬性的最大特色是,不管是否同源,只要在同一個窗口裏,前一個網頁設置了這個屬性,後一個網頁能夠讀取它。
父窗口先打開一個子窗口,載入一個不一樣源的網頁,該網頁將信息寫入window.name
屬性。
window.name = data;
接着,子窗口跳回一個與主窗口同域的網址。
location = 'http://parent.url.com/xxx.html';
而後,主窗口就能夠讀取子窗口的window.name
了。
var data = document.getElementById('myFrame').contentWindow.name;
這種方法的優勢是,window.name
容量很大,能夠放置很是長的字符串;缺點是必須監聽子窗口window.name
屬性的變化,影響網頁性能。
上面兩種方法都屬於破解,HTML5爲了解決這個問題,引入了一個全新的API:跨文檔通訊 API(Cross-document messaging)。
這個API爲window
對象新增了一個window.postMessage
方法,容許跨窗口通訊,不論這兩個窗口是否同源。
舉例來講,父窗口http://aaa.com
向子窗口http://bbb.com
發消息,調用postMessage
方法就能夠了。
var popup = window.open('http://bbb.com', 'title');popup.postMessage('Hello World!', 'http://bbb.com');
postMessage
方法的第一個參數是具體的信息內容,第二個參數是接收消息的窗口的源(origin),即"協議 + 域名 + 端口"。也能夠設爲*
,表示不限制域名,向全部窗口發送。
子窗口向父窗口發送消息的寫法相似。
window.opener.postMessage('Nice to see you', 'http://aaa.com');
父窗口和子窗口均可以經過message
事件,監聽對方的消息。
window.addEventListener('message', function(e) { console.log(e.data);},false);
message
事件的事件對象event
,提供如下三個屬性。
event.source
:發送消息的窗口
event.origin
: 消息發向的網址
event.data
: 消息內容
下面的例子是,子窗口經過event.source
屬性引用父窗口,而後發送消息。
window.addEventListener('message', receiveMessage);function receiveMessage(event) { event.source.postMessage('Nice to see you!', '*');}
event.origin
屬性能夠過濾不是發給本窗口的消息。
window.addEventListener('message', receiveMessage);function receiveMessage(event) { if (event.origin !== 'http://aaa.com') return; if (event.data === 'Hello World') { event.source.postMessage('Hello', event.origin); } else { console.log(event.data); }}
經過window.postMessage
,讀寫其餘窗口的 LocalStorage 也成爲了可能。
下面是一個例子,主窗口寫入iframe子窗口的localStorage
。
window.onmessage = function(e) { if (e.origin !== 'http://bbb.com') { return; } var payload = JSON.parse(e.data); localStorage.setItem(payload.key, JSON.stringify(payload.data));};
上面代碼中,子窗口將父窗口發來的消息,寫入本身的LocalStorage。
父窗口發送消息的代碼以下。
var win = document.getElementsByTagName('iframe')[0].contentWindow;var obj = { name: 'Jack' };win.postMessage(JSON.stringify({key: 'storage', data: obj}), 'http://bbb.com');
增強版的子窗口接收消息的代碼以下。
window.onmessage = function(e) { if (e.origin !== 'http://bbb.com') return; var payload = JSON.parse(e.data); switch (payload.method) { case 'set': localStorage.setItem(payload.key, JSON.stringify(payload.data)); break; case 'get': var parent = window.parent; var data = localStorage.getItem(payload.key); parent.postMessage(data, 'http://aaa.com'); break; case 'remove': localStorage.removeItem(payload.key); break; }};
增強版的父窗口發送消息代碼以下。
var win = document.getElementsByTagName('iframe')[0].contentWindow;var obj = { name: 'Jack' };// 存入對象win.postMessage(JSON.stringify({key: 'storage', method: 'set', data: obj}), 'http://bbb.com');// 讀取對象win.postMessage(JSON.stringify({key: 'storage', method: "get"}), "*");window.onmessage = function(e) { if (e.origin != 'http://aaa.com') return; // "Jack" console.log(JSON.parse(e.data).name);};
同源政策規定,AJAX請求只能發給同源的網址,不然就報錯。
除了架設服務器代理(瀏覽器請求同源服務器,再由後者請求外部服務),有三種方法規避這個限制。
JSONP
WebSocket
CORS
JSONP是服務器與客戶端跨源通訊的經常使用方法。最大特色就是簡單適用,老式瀏覽器所有支持,服務器改造很是小。
它的基本思想是,網頁經過添加一個<script>
元素,向服務器請求JSON數據,這種作法不受同源政策限制;服務器收到請求後,將數據放在一個指定名字的回調函數裏傳回來。
首先,網頁動態插入<script>
元素,由它向跨源網址發出請求。
function addScriptTag(src) { var script = document.createElement('script'); script.setAttribute("type","text/javascript"); script.src = src; document.body.appendChild(script);}window.onload = function () { addScriptTag('http://example.com/ip?callback=foo');}function foo(data) { console.log('Your public IP address is: ' + data.ip);};
上面代碼經過動態添加<script>
元素,向服務器example.com
發出請求。注意,該請求的查詢字符串有一個callback
參數,用來指定回調函數的名字,這對於JSONP是必需的。
服務器收到這個請求之後,會將數據放在回調函數的參數位置返回。
foo({ "ip": "8.8.8.8"});
因爲<script>
元素請求的腳本,直接做爲代碼運行。這時,只要瀏覽器定義了foo
函數,該函數就會當即調用。做爲參數的JSON數據被視爲JavaScript對象,而不是字符串,所以避免了使用JSON.parse
的步驟。
WebSocket是一種通訊協議,使用ws://
(非加密)和wss://
(加密)做爲協議前綴。該協議不實行同源政策,只要服務器支持,就能夠經過它進行跨源通訊。
下面是一個例子,瀏覽器發出的WebSocket請求的頭信息(摘自維基百科)。
GET /chat HTTP/1.1Host: server.example.comUpgrade: websocketConnection: UpgradeSec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==Sec-WebSocket-Protocol: chat, superchatSec-WebSocket-Version: 13Origin: http://example.com
上面代碼中,有一個字段是Origin
,表示該請求的請求源(origin),即發自哪一個域名。
正是由於有了Origin
這個字段,因此WebSocket纔沒有實行同源政策。由於服務器能夠根據這個字段,判斷是否許可本次通訊。若是該域名在白名單內,服務器就會作出以下回應。
HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=Sec-WebSocket-Protocol: cha
CORS是跨源資源分享(Cross-Origin Resource Sharing)的縮寫。它是W3C標準,是跨源AJAX請求的根本解決方法。相比JSONP只能發GET
請求,CORS容許任何類型的請求。
下一篇文章,我會詳細介紹,如何經過CORS完成跨源AJAX請求。