同源策略

同源策略

在浏览器中，保证访问数据安全的基础就是同源策略

同源策略是由Netscape提出的一个著名的安全策略，现在所有支持JavaScript 的浏览器都会使用这个策略。

实际上，这种策略只是一个规范，并不是强制要求，各大厂商的浏览器只是针对同源策略的一种实现。它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。

如果Web世界没有同源策略，当你登录FreeBuf账号并打开另一个站点时，这个站点上的JavaScript可以跨域读取你的FreeBuf账号数据，这样整个Web世界就无隐私可言了。

前言

我们可以设想个场景：

学校中有个班，班级开放了一个窗口给家长，家长可以通过改窗口询问自己孩子的相关信息，班级里面的每个学生都是互不相关、互不影响的单一个体，每个学生和家长都是属于同一家庭，当同一家庭里面的家长来问该家庭的孩子的信息时候，窗口就会给出相应的信息。要是不是同一家庭的家长来问其他孩子的信息，窗口不加验证就回答，这样孩子的安全就无法保证了。 只有同一家庭家长和孩子可以互传信息，这样就保证了信息传递的安全性

下面我们假设：

这个窗口我们想想成浏览器窗口，里面的学生和家长就是一个个单独的网站，而每一个家庭就是同域，这样只有同一个域下的单独的网站之间才能互相传递信息，这样才能保证数据上的安全性

这个就是简单的同源策略的作用

同源策略的三大要素

什么情况下同源？

包括了三大要素：

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

COOKIE

cookie是服务器写入浏览器的一段信息，只有同源的可以共享，但是要求绝对同源的情况下，比如https://reg.163.com 和 http://mail.163.com 这种属于不同源的，为啥我们在登入了reg之后是再登入mail不需要重新登入

浏览器允许通过document.domian=163.com 用来设置共享cookie

网站要求用户登入自己的账户，登入后，认证接口就会下发给浏览器一个cookie，通过

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

完成了cookie的植入，通过这种策略就完成了网站的统一认证登入，这个在cookie中就会有一个相对比较重要的cookie参数，比如在163.com就是NTES_SESS，也就是你只要拿到这个的值就能登入到网易的所有的站点了

但是这种方式无法LocalStorage 和 IndexDB 这种产生了其他的一些设置策略

iframe

如果两个网页不同源，就无法拿到对方的DOM。

查看以下代码：

<iframe id="myIFrame" src="http://www.163.com"></iframe>

<script>
document.getElementById("myIFrame").contentWindow.document
</script>

观察console就会发现报错。

document.getElementById("myIFrame").contentWindow.document
// Uncaught DOMException: Blocked a frame from accessing a cross-origin frame.

是无法得到不同域的document的dom元素的

有几个方案可以解决跨域的一些问题

片段识别符（fragment identifier）

window.name

跨文档通信API（Cross-document messaging）

跨域比较有意思，可以参见《PostMessage跨域漏洞》和《跨域获取数据小结》

AJAX

不同域的ajax是无法请求的，AJAX要想解决域的信息可以采用：

JSONP

WebSocket

CORS

JSONP

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

WebSocket

WebSocket是一种通信协议，使用ws://（非加密）和wss://（加密）作为协议前缀。该协议不实行同源政策，只要服务器支持，就可以通过它进行跨源通信。

CORS

这个是现在用到比较广的一种方式，全称是"跨域资源共享"。

它允许浏览器向跨源服务器，发出XMLHttpRequest请求，从而克服了AJAX只能同源使用的限制。

CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。

整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。

因此，实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。

浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。

简单请求

请求方法是以下三种方法之一： HEAD GET POST

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

Accept

Accept-Language

Content-Language

Last-Event-ID

Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

简单请求发出的案例如下，就是简单的ajax请求方式，只不过在header头部增加了Origin：

GET /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

服务器返回的信息：

Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: FooBar
Content-Type: text/html; charset=utf-8

Access-Control-Allow-Origin: 允许的Origin

Access-Control-Allow-Credentials: 可选，是否允许发送Cookie

Access-Control-Expose-Headers:可选，CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader('FooBar')可以返回FooBar字段的值。

非简单请求

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

非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。

也就是会首先发出一个option请求

无源的情况

某些情况下web应用会产生像about、javascript、data这样的伪协议创建无须服务器内容的HTML页面，这些页面的数据完全来自客户端

由于原始的同源策略没有考虑到这个场景，也就是完全不同的域创建的about:blank文档就属于同源的页面了

about:blank 页面的继承

about：`可以创建一个最小的dom层级文档，父级页面可以在其中写入任意数据

看以下代码：

<iframe src="about:blank" name="test"></iframe>
<script>
frames['test'].document.body.innerHTML="<h1>test</h1>";
</script>

在多数浏览器中，大多数的about:blank都会创建一个新的页面，这个页面继承了发起页的SOP源。

about:blank页面对源的继承特殊情况如下：

IE: 如果新页面是在iframe中那么它是可以被父页面访问到，也就是它继承了父页面的源

PS：无源产生的问题很多，继续研究，后续补充