基于同源策略对CORS和JSONP的初步认识

前言

这几天在拜读道哥的<<白帽子讲Web安全>>这本书,在看浏览器安全这章第一次接触到同源策略(Same Origin Policy)这个词,再加上道哥对SOP(Same Origin Policy)的字里行间都透露着其不二般的重要性,所以SOP自然毫无疑问值得我写一篇博客来记录对它的学习了!

此处以一张来自wooyun镜像的截图证明SOP在浏览器安全中的地位

正文开始

什么是同源策略

首先要了解同源包含了"三个相同"

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

下面先以http://www.0wl.org/hello/csdn.html为例子来了解了解"同源"的概念

http://www.0wl.org/hello/csdn.html	作为参照
http://www.0wl.org/hello/csdn.html	同源
https://www.0wl.org/hello/csdn.html	不同源(协议不同)
http://www.xxx.org/hello/csdn.html	不同源(域名不同)
http://www.0wl.org:6666/hello/csdn.html	不同源(端口不同)

现在来看看SOP的介绍

同源策略是一种约定，是浏览器最核心也最基本的安全功能，主要体现在SOP会限制来自不同源的文档和脚本对当前源的文档数据的读取或设置某些属性，是用于隔离潜在恶意文件的重要安全机制。

注意"限制"二字,同源策略只是对源做了限制,而并非是完全隔离.看到这里,你或许会想,为什么不完全隔离呢,这样岂不是就不会出现跨域的bug了,简直就是一劳永逸啊,我在查阅相关资料之前也是这么想的,但是在实际中这种方法的可行性实在太低,下面让我来为你解释为何不行.

你可以试想一下,假如网站把html,javascript,image,css等文件全部放在一台服务器上,像个人博客这种小网站或许可以,但是稍微大一点的网站服务器肯定是扛不住的,而且极大的降低了网站的灵活性和可用性,所以浏览器为了提升网站的灵活性,只好只好降低一点点安全性咯,同时这就是为什么我们在遵循同源策略的网站中还能看见img , script, src, style等标签的身影.

写到到这里,对同源策略的初步认识也就结束了,下面我们看看在同源策略控制下的web世界被做了哪些限制.

iframe限制

• 可以访问同域资源, 可读写
• 访问跨域页面时, 只读

Ajax限制

Ajax 的限制比 iframe 限制更严

• 同域资源可读写
• 跨域请求会直接被浏览器拦截.(chrome下跨域请求不会发起, 其他浏览器一般是可发送跨域请求, 但响应被浏览器拦截)

Script限制

script并无跨域限制, 这是因为script标签引入的文件不能够被客户端的 js 获取到, 不会影响到原页面的安全, 因此script标签引入的文件没必要遵循浏览器的同源策略. 相反, ajax 加载的文件内容可被客户端 js 获取到, 引入的文件内容可能会泄漏或者影响原页面安全, 故, ajax必须遵循同源策略.

但是千万不要以为对web做了限制就安全了,因为黑客的思维是无法被限制的,在后期的博客中我会介绍一些绕过同源策略的方式.接下来先讲讲一些"正确"的跨域访问方式.

跨域访问

XMLHttpRequest的跨域

JSONP

JSONP就是利用 `` 标签的跨域能力实现跨域数据的访问，请求动态生成的JavaScript脚本同时带一个callback函数名作为参数。
服务端收到请求后，动态生成脚本产生数据，并在代码中以产生的数据为参数调用callback函数。

CORS

CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）。它是跨域AJAX请求的根本的解决办法.相比JSONP的只能以GET请求,CORS支持所有类型的HTTP请求.其请求方式也可以分为简单请求和非简单请求。

简单请求

只要同时满足以下两大条件，就属于简单请求。
a. 请求方法是以下三种方法之一:

• HEAD
• GET
• POST

b.HTTP的头信息不超出以下几种字段:

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

非简单请求

非简单请求会发出一次预检测请求，返回码是204，预检测通过才会真正发出请求，这才返回200。这里通过前端发请求的时候增加一个额外的headers来触发非简单请求

WebSocket

WebSocket是一种新的通信协议，能够在一个持久连接上提供全双工、双向通信。使用url模式也略有不同。使用ws://(非加密)和wss://(加密)作为协议前缀.该协议并没有遵循同源策略,只要服务器支持,就可以通过该协议进行跨域通信.

代理

• 正向代理

  需要借助同源的代理服务器，浏览器先将请求发送给代理服务器，代理服务器接收请求并其转发给目标数据服务器，因为不同源的两个服务器的交互不遵循同源策略

• 反向代理

  可以用Nginx反向代理来实现(服务端之间的资源交互不会有跨域限制)

Cookie的跨域

同源的页面才可以共享cookie，但是如果两个源的一级域名相同，二级域名不同，浏览器可以通过设置document.domain来共享cookie

这里只介绍了我认为会涉及到安全问题的跨域访问的种类(剩下的等日后深入的时候在做详解),讲这么多,其实最主要的目的就是学习基于SOP的Web安全问题,即JSONP劫持和CORS跨域漏洞.

所以,下面先粗略的了解了解常见的安全问题,此处只作粗略地介绍.因为我后续还要写关于对CORS漏洞和JSONP劫持深入学习的博客.

安全问题

CORS 跨域漏洞

关于 CORS 的相关介绍上面已经写了，这个漏洞产生的主要原因是服务端的配置不当。

CORS跨域漏洞的攻击流程

若用户登陆了含有CORS配置的网站0wl.com，同时又访问了攻击者提供的一个链接Hacker.com
然后从Hacker.com网站再向0wl.com这个网站发起获取敏感数据的请求
如果网站0wl.com配置了Access-Control-Allow-Origin头且为预期
那么攻击者就可以通过跨域获取用户的敏感数据了

以下是Server端通过设置http请求头来指定允许请求的域的声明：

Access-Control-Allow-Origin: http://0wl.com

如果发起请求的域不在Server端的白名单内，那么浏览器将会屏蔽响应包,不予回应。

是否允许请求包携带 Cookie的声明：

Access-Control-Allow-Credentials: true

出于对安全性的考虑，CORS 协议中有一个特殊限制:
服务端不能在既允许所有请求域的情况下，又同时允许请求包携带 Cookie。

CORS结合XSS漏洞进行利用

在有的情况下,假如A站的CORS配置中有信任自身的任何一个子域的许可，那也就意味着,如果该网站的某个子域存在XSS漏洞,那么此时攻击者将轻而易举地就可以通过这个XSS漏洞去读取其他任意子域的资源,甚至还可以与其他漏洞打组合拳,进行联动攻击。

JSONP 劫持

jsonp 劫持就是攻击者获取了本应该传给网站其他接口的数据

下面是JSONP漏洞利用的过程(图片来源于互联网)

1）用户在网站B 注册并登录，网站B 包含了用户的id，name，phone number,email,address等信息
2）用户通过浏览器向网站A发出URL请求
3）网站A向用户返回响应页面，响应页面中注册了JavaScript的回调函数和向网站B请求的script标签
4）用户收到响应，解析JS代码，将回调函数作为参数向网站B发出请求
5）网站B接收到请求后，解析请求的URL，以JSON 格式生成请求需要的数据，将封装的包含用户信息的JSON数据作为回调函数的参数返回给浏览器，网站B返回数据
6）网站B数据返回后，浏览器则自动对步骤4返回的JSON格式数据进行处理，通过alert弹窗展示了用户在网站B的注册信息。另外也可将JSON数据回传到网站A的服务器，这样网站A利用网站B的JSONP漏洞便获取到了用户在网站B注册的信息

对于以上的攻击原理及实现我将在后续的博客中写.感兴趣的可以关注我后期的博客哦!

参考文章
对于浏览器的同源策略你是怎样理解的呢？
浏览器的同源策略详解
浏览器同源政策及其规避方法