NoSec
首发于NoSec

谈谈同源策略

同源策略

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

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

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

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

前言

我们可以设想个场景:

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

下面我们假设:

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

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

同源策略的三大要素

什么情况下同源?

包括了三大要素:

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

COOKIE

cookie是服务器写入浏览器的一段信息,只有同源的可以共享,但是要求绝对同源的情况下,比如网易帐号中心 和 163网易免费邮--中文邮箱第一品牌 这种属于不同源的,为啥我们在登入了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就会发现报错。

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

1. JSONP

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

2. WebSocket

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

3. CORS

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

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

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

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

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

浏览器将CORS请求分成两类:简单请求(simple request)和非简单请求(not-so-simple request)。

3.1 简单请求

请求方法是以下三种方法之一:
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: Domain Default page
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

服务器返回的信息:

Access-Control-Allow-Origin: Domain Default page
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字段的值。

3.2非简单请求

非简单请求是那种对服务器有特殊要求的请求,比如请求方法是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:除了同源绕过的漏洞外,还有无源的通用跨域,还有特权域的xss问题,都是和源有关的问题,正在研究学习中。网上有些资料了,我这还没有发现过案例。

编辑于 2017-04-26

文章被以下专栏收录