跨域整理总结

@sakila1012 2018-03-06 08:19:39发表于 sakila1012/blog AJAX

写在前面

  1. 跨域如何产生的
  2. 跨域的解决方法

浏览器安全的基石是“同源策略”(same-origin policy)。

一、介绍

1.1 含义

1995年,同源策略由 Netscape 公司引入浏览器。目前,所有的浏览器都支持这个政策。
最初,它的含义是指,A网页设置的 Cookie,B网页不能打开,除非这两个网页“同源”。同源指的是“三个相同”。

  • 协议相同
  • 域名相同
  • 端口相同

举例来说,http://www.example.com/dir/page.html这个网址,协议是 http://,域名是 www.example.com ,端口是 80(默认端口号可以省略)。它的同源情况如下。
* http://www.example.com/dir2/other.html:同源
* http://example.com/dir/other.html:不同源(域名不同)
* http://v2.www.example.com/dir/other.html:不同源(域名不同)
* http://www.example.com:81/dir/other.html:不同源(端口不同)

1.2 目的

同源策略的目的,是为了保证用户信息的安全,防止恶意的网站窃取数据。
设想这样的一个情况:A网站是一家银行,用户登陆以后,又去浏览器其他网站。如果其他网站可以读取A网站的 Cookie,会发生什么?
很显然,如果 Cookie 包含隐私(比如存款总额),这些信息就会泄露。更可怕的是,Cookie 往往用来保存用户的登录状态,如果用户没有退出登录,其他网站就可以冒充用户,为所欲为。因为浏览器同时还规定,提交表单不受同源政策的限制。

由此可见,“同源策略”是必须的,否则 Cookie 可以共享,互联网就毫无安全可言了。

1.3 限制范围

随着互联网的发展,“同源策略”越来越严格了。目前,如果非同源,共有三种行为受到限制。

(1)  Cookie、LocalStorage 和 IndexDB 无法读取。
(2)  DOM 无法获得。
(3)  AJAX 请求不能发送

虽然这些限制是必要的,但是有时很不方便,合理的用途也受到影响。下面,将详细介绍,如何规避上面三种限制。

##二 、Cookie
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.都可以读取这个 Cookie。

##三、iframe
如果两个网页不同源,就无法拿到对方的 DOM。典型的例子是 iframe 窗口和 window.open 方法打开的窗口,他们与父窗口无法通信。比如,父窗口运行下面的命令,如果 iframe 窗口不是同源,就会报错。

document.getElementById("myFrame").contentWindow.document

上面命令中,父窗口想获取子窗口的 DOM,因为跨源导致报错。
反之亦然,子窗口获取主窗口的 DOM 也会报错。

window.parent.document.body

如果两个窗口一级域名相同,只有二级域名不同,那么设置上一节介绍的 document.domain 属性,就可以规避同源策略,拿到 DOM。

对于完全不同源的网站,目前有三种方法,可以解决跨域窗口的通信问题。

片段识别符
window.name
跨文档通信 API(Cross-document messaging)

3.1 片段识别符
片段识别符(fragment indentifier)指的是,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;

3.2 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 属性的变化,影响网页性能。

3.3 window.postMessage

上面两种方法都属于破解,HTML5为了解决这个问题,引入一个全新的 API:跨文档通信 API(cross-document mesaging)。
这个 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 方法的第一个参数是具体信息内容,第二个参数是接受消息的窗口的源,即“协议+域名+端口”。也可以设为 *,表示不限制域名,向所有窗口发送。

子窗口向父窗口发送消息的写法类似。

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 reeiveMessage(event) {
   if(event.origin !== 'http://aaa.com') return;
  if(event.data === 'Hello World') {
  event.source.postMessage('Hello', event.origin);
} else {
  console.log(event.data);
}
}

3.4 LocalStorage

通过 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.postMesage(JSON.stringify({key: 'storage', method: 'set', data: obj}), 'http://bbb.com');
//读取对象
window.onmessage = function(e) {
   if(e.origin != 'http://aaa.com') return;
   console.log(JSON.parse(e.data).name);
}

四、AJAX

同源策略规定,AJAX请求只能发送给同源的网址,否则就会报错。
除了架设服务器代理(浏览器请求同源服务器,再由后者请求外部服务),有三种方法规避这个限制。

JSONP
Websocket
CORS

4.1 JSONP

JSONP是服务器与客户端跨源通信的常用方法。最大的特点就是简单适用,老式浏览器全部支持,服务器改造非常小。
它的基本思想是,网页通过添加一个 <script>元素,向服务器请求 JSONP 数据,这种做法不受同源策略限制,服务器收到请求后,将数据放在一个指定名字的回调函数里传回来。
首先,网页动态插入<script>元素,由它向跨源网址发出请求。

function addScript(src) {
  var script = document.createElement('script');
  script.setAttribute('type','text/javascript');
  script.src = src;
  document.body.appendChild(script);
}
window.onload = function() {
  addSciptTag('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'
})

由于 元素请求的脚本,直接作为代码运行。这时,只要浏览器定义了 foo 函数,该函数就立即调用。作为参数的JSON数据视为JavaScript 对象,而不是字符串,因此避免使用 JSON.parse的步骤。

JSONP 缺点
JSONP实现跨域访问非常方便,简单易用,但是也有不足的地方:
首先,从它的实现方式可以看出,它是发起一个资源获取请求,是GET类型,在日常开发中常用的请求类型还有POST,PUT,DELETE,而JSONP只发起GET请求,是它的一大短板。

其次,JSONP是从其他域中加载代码并执行,如果其他域不安全,很有可能会在执行的代码中夹杂着一些恶意代码,所以在使用JSONP时一定要保证被请求方安全可靠。

最后,由于它的请求类型不是XHR,就缺少了一些事件处理程序,要追踪JSONP请求是否失败并不容易,或者为JSONP请求增加定时器,超时就视为请求失败,接下来就再次发送请求或者做其他事情,但是每个用户的网络情况并不能保证,这样做也不是万全之策。

4.2 WebSocket

WebSocket 是一种通信协议,使用ws://(非加密)和wss://(加密)作为协议前缀。该协议不实行同源策略,只要服务器支持,就可以通过它进行跨源通信。
下面是一个例子,浏览器发出的WebSocket 请求的头信息(摘自维基百科)

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://example.com

上面的代码中,有一个字段是 Origin,表示该请求的请求源(origin),即发自哪个域名。
正是因为有了 Origin 这个字段,所以 WebSocket 才没有实行同源策略。因为服务器可以根据这个字段,判断是否许可这个字段,判断是否许可本次通信。如果该域名在白名单内,服务器会做出如下回应。

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

4.3 CORS

CORS 是跨源资源分享(Cross-Origin Resource Sharing)的缩写。它是W3C标准,是跨源AJAX请求的根本解决方法。相比JSONP只能发 GET 请求,CORS允许任何类型的请求。
具体实现为:使用自定义的HTTP头部让浏览器与服务器进行沟通,从而决定跨域请求或响应时应该成功还是失败。

比如说发起一个 GET 跨域请求,Content-type 是 text/plain,在发送跨域请求前,浏览器会为http头部加上一个额外的Origin头部,其中包含了页面的源信息(协议、域名、端口),这个额外的 Origin 决定了服务器是否响应该请求。一个 Origin 头部实例:

Origin: https://www.somewhere-else.net

如果服务器认可该请求就会在响应头上加上 Access-Control-Allow-Origin标志字段,值可以是与请求头带来的Origin相同,如果该服务器上的是公共资源,值就是"*"。

Access-Control-Allow-Origin: https://www.somewhere-else.net

如果响应头中没有这个字段,说明服务器拒绝了这次跨域请求,会抛出一个错误,但是并不能被 xhr 的onerror 事件捕获。默认情况下跨域请求都是不带凭证(cookie,HTTP认证及服务端SSL证明等),通过修改 xhr 对象的 withCredentials (IE10以前的版本不支持该属性)设置为true,可以指定某个请求携带凭证。如果服务器允许跨域请求携带凭证响应头部会有标识。

Access-Control-Allow-Credentials: true 

如果发送的是带凭证的请求,响应头里却没有这个字段,那么浏览器就不会把响应交给JS,意思是XHR获取到的 responseText 为空,status 为0,这个时候onerror可以捕获到该错误。

XHR对象在跨域时也是有限制的:

  • 不能使用 setRequestHeader() 来设置头部
  • 默认情况下无法发送cookie
  • 调用 getAllResponseHeaders() 方法总会返回空字符串

CORS 的实现

var xhr = new XMLHttpRequest();
xhr.onreadystateChange = function() {
  if(xhr.readyState === 4) {
    if(xhr.status >= 200 && xhr.status <= 300 || xhr.status === 304) {
       alert(xhr.responseText);
    } else {
      alert("error ", xhr.status);
    }
  }
}
xhr.open("get", "http://www.somewhere-else.com/page", true);
xhr.send(null)

发送CORS 请求和发送普通的xhr对象差别不大,只需要在地址处写绝对地址即可。跨域所需要做的工作就交给浏览器,对于用户来说是透明。

IE浏览器是用 XDR(XDomainRequest)来实现CORS的,它和XHR相似,但是能提供安全可靠的跨域通信。

  • cookie不能随请求发送,也不会随响应返回
  • 只能设置请求头部信息中 Content-type 字段
  • 不能访问响应头部信息
  • 只支持 GET 和 POST 请求
    XDR 对象和xhr的使用方法类似,也是创建一个XDomainRequest的实例,调用open() 方法,在调用 send() 方法,但是与 xhr 对象的 open() 不同,XDR对象的 open() 方法只接受两个参数:请求类型和URL,XDR发送的请求是异步执行的。而且XDR 对象无法访问 status 属性,所以在使用 XDR 时一定得通过 onerror 事件处理程序来捕获错误。