同源策略限制 & 规避

同源策略

同源策略是一个重要的安全策略，它用于限制一个origin的文档或者它加载的脚本如何能与另一个源的资源进行交互。它能帮助阻隔恶意文档，减少可能被攻击的媒介。提交表单不受同源政策的限制。因为不需要响应。

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

限制范围：
（1） Cookie、LocalStorage 和 IndexDB 无法读取。
（2） DOM 无法获得。
（3） AJAX 请求不能发送（是否携带cookie）。

规避

一、共享cookie

两个网页一级域名相同，只是二级域名不同。

document.domain = 'example.com';
document.cookie = "test1=hello";

Set-Cookie: key=value; domain=.example.com; path=/

二、iframe

DOM 获取

两个网页完全不同源，无法拿到dom。两个网页一级域名相同，只是二级域名不同

document.domain = 'example.com';

document.getElementById("myIFrame").contentWindow.document

window.parent.document.body

跨域窗口的通信

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

1. 片段识别符（fragment identifier）

2. window.name

3. 跨文档通信API（Cross-document messaging）window.postMessage

1. 片段识别符（fragment identifier）

var src = originURL + '#' + data;
document.getElementById('myIFrame').src = src;

window.onhashchange = checkMessage;

parent.location.href= target + "#" + hash;

2. window.name
浏览器窗口有window.name属性。这个属性的最大特点是，无论是否同源，只要在同一个窗口里，前一个网页设置了这个属性，后一个网页可以读取它。

这种方法的优点是，window.name容量很大，可以放置非常长的字符串；缺点是必须监听子窗口window.name属性的变化，影响网页性能。

3. postMessage

var popup = window.open('http://bbb.com', 'title');
popup.postMessage('Hello World!', 'http://bbb.com');

window.opener.postMessage('Nice to see you', 'http://aaa.com');

window.addEventListener('message', function(e) {},false);

window.postMessage, 传递自定义message 或 LocalStorage 数据。

三、AJAX

异步JavaScript和XML。快速地将增量更新呈现在用户界面上，而不需要重载（刷新）整个页面。

JSONP ： http://example.com/ip?callback=foo

WebSocket ： 该协议不实行同源政策，只要服务器支持，就可以通过它进行跨源通信。

CORS ： 跨域资源共享

CORS

CORS需要浏览器和服务器同时支持。目前，主流的浏览器都支持cors。

整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。

浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。因此，实现CORS通信的关键是服务器。 只要服务器实现了CORS接口，就可以跨源通信。

简单请求（simple request）

（1) 请求方法是以下三种方法之一：

• HEAD
• GET
• POST

（2）HTTP的头信息不超出以下几种字段：

• Accept
• Accept-Language
• Content-Language
• Last-Event-ID
• Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

基本流程

对于简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段。如果Origin指定的域名

- 不在许可范围内，服务器会返回一个正常的HTTP回应。

浏览器收到这个回应发现这个回应的头信息没有包含Access-Control-Allow-Origin字段，就知道错了，从而会抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。此时HTTP回应的状态码可能是200。

- 在许可范围内，服务器返回的响应会多出几个头信息字段。

• Access-Control-Allow-Origin：该字段是必须的，其值可能是请求时Origin字段的值，也可能是一个*，表示接受任意域名请求。
• Access-Control-Allow-Credentials：该字段可选，其值类型是布尔型，表示是否允许发送Cookie。默认情况下Cookie不包括在CORS请求中。
• Access-Control-Expose-Headers ：该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。

withCredentials 属性，携带cookie

默认情况下，CORS请求默认不发送Cookie和Http认证信息，如果要把Cookie发送到服务器，首先要指定Access-Control-Allow-Credentials字段。

Access-Control-Allow-Credentials = true

另一方面，需要在AJAX请求中打开withCredentials属性。 请求携带cookie

xhr.withCredentials = true;

如果设置该属性为false，即使服务器同意发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会处理。

如果省略withCredentials设置，有的浏览器还是会一起发送Cookie。这时，可以显式关闭withCredentials。

需要注意的是，如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。

同时，Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。

非简单请求（not-so-simple request）

非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。

非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。

"预检"请求用的请求方法是OPTIONS，通过后浏览器才会发出正式的XMLHttpRequest请求，否则就报错。更多详细见浏览器同源政策及其规避方法。

一旦服务器通过了"预检"请求，以后每次浏览器正常的CORS请求，就都跟简单请求一样，会有一个Origin头信息字段。服务器的回应，也都会有一个Access-Control-Allow-Origin头信息字段。

预检响应头

• Access-Control-Allow-Origin：每次回应都必定包含的。
• Access-Control-Allow-Methods ： 首部字段用于预检请求的响应。其指明了实际请求所允许使用的 HTTP 方法。
• Access-Control-Allow-Headers ：如果浏览器请求包括Access-Control-Request-Headers字段，则Access-Control-Allow-Headers字段是必需的。用于预检请求的响应，它也是一个逗号分隔的字符串，其指明了实际请求中允许携带的首部字段，不限于浏览器在"预检"中请求的字段。
• Access-Control-Max-Age：该字段可选，用来指定本次预检请求的有效期，单位为秒。上面结果中，有效期是20天（1728000秒），即允许缓存该条回应1728000秒（即20天），在此期间，不用发出另一条预检请求。
• Access-Control-Allow-Credentials：同简单请求。

与JSONP的比较

CORS与JSONP的使用目的相同，但是比JSONP更强大。
JSONP只支持GET请求，CORS支持所有类型的HTTP请求。JSONP的优势在于支持老式浏览器，以及可以向不支持CORS的网站请求数据。

参考：
阮一峰老师【浏览器同源政策及其规避方法】
MDN【浏览器的同源策略】
Access-Control-Allow-Headers等基础常识