浏览器同源策略理解

1、背景说明

昨天领导要求给研发提个单，要求加上X-Frame-Options头，和他说这个头部以前客户已经要求加过了，顺带说了这东西就是为了防范攻击者经过iframe等引用页面进行点击劫持用的。

后来他又询问说经过iframe引入后是否是用户在iframe中的输入及操做的响应结果是否iframe外层都能经过js直接或取到，由于从消息流向来讲，消息确定是先到达浏览器再传到web页面再传到web页面内的iframe；而后他又从另外一个角度问，iframe内外层是不一样的网站，扩展到网络上，是否是A站的js也能够请求B站的接口？若是是，那这叫什么同源？

对于前一个问题，没仔细探究过只好回答说你按客户端编程的思路来讲外层确实能够获取流向内层的数据，我只能说个人经验和我看的书都告诉我因为同源策略外层不能访问内层的数据内层也不能访问外层的数据，你要问原理我就说不上来。对于后一个问题，后来想了想这就是以前讨论过的跨域请的问题了，服务端经过浏览器提交的Origin头决定是否进行响应，浏览器经过服务端返回的Access-Control-Allow-Origin头决定是否进行解析。

 

2、同源策略

2.1 同源的含义

“同源”这个词最开始在哪看到已经不太记得了，但这个词从一开始就以为很好理解：同IP同端口就是同源，反之就不一样源。

如今看网上说，同协议同域名同端口就是同源。因为CDN等机制用域名访问一个网站并不必定老是一个IP，因此域名+端口这个说法确实更严谨一些。至于同域名/同IP难道还有不一样协议这个问题，就要说远一些，最近本身常常说渗透测试的第一步是威胁建模所谓威胁建模就是看系统开放了什么端口各端口下面使用了哪些协议，上周也和一个朋友这样说她忽然问一个端口下会有多套不一样的协议吗而后又接着本身答这种状况应该比较少吧。回头仔细想本身一个端口下可有多套协议的认知，大概来源于公司产品的私有协议端口既可传输控制请求也可传输视频流数据；从原理上而言，一个端口实现多套协议，重点在于数据包协议类型判断上，只要判断接收到的数据包类型而后转发到相应的进程上处理就能够了；从实践上看，SSLH等就能够实现多套协议只开一个端口。即总的而言，首先一个端口多套协议是有可能的----但确实这种场景比较少；而后我并不肯定浏览器是否会将同域名/IP同端口不一样协议视为不一样源，只能说直觉上同协议也是一项标准确实更准确一些。

 

2.2 同源策略的含义

如前面所说，总的而言“同源”仍是比较好理解的，但同源策略具体是什么呢？或者说同源又怎样不一样源又怎样？总的而言有如下三点限制：

一是来自一个源的js只能读写本身源的存储不能读写其余源的存储，存储包括Cookie、Session Storage、Local Storage、Cache、Indexed DB等。

二是来自一个源的js只能读写本身源的DOM树不能读取其余源的DOM树。即若是开始讨论，iframe内外层不一样源就不能相互操做，外层想获取内层的内容只能使用点击劫持配合；实现原理亦如前所述未知。

三是通常而言来自一个源的js只能向本身源的接口发送请求不能向其余源的接口发送请求。固然其实本质是，一方面浏览器发现一个源的js向其余源的接口发送请求时会自动带上Origin头标识来自的源，让服务器能经过Origin判断要不要向应；另外一方面，浏览器在接收到响应后若是没有发现Access-Control-Allow-Origin容许发送请求的域进行请求那也不容许解析。本身以前也抱怨过，又不是服务器不响应服务器响应了不浏览器不（容许js）解析是否是没什么意义的画蛇添足；如今看来，经过本身写python等方法也确实能请求其余服务器并解析其结果，浏览器没有Access-Control-Allow-Origin容许不解析一是说维护了本身同源策略的思想二是说至少能够保证不会在本身身上出现A域可随便探测B域的状况，因此也不能说彻底没用。

四是来自一个源的js不能随意操做浏览器以外的资源。好比打开命令提示符、执行系统命令等等。假若你访问一个网站该网站的js能够直接调用系统命令给你电脑进行添加用户等操做，那问题就大了。

 

2.3 同源策略说明

不是说来自A域的js不能操做B域吗，那咱们常常经过<script>标签从别的网站引入js文件而后用来操做本身网站的内容，这不是明显不符合同源策略吗？

对于这个问题，我的是这样考虑，从其余网站引入的js文件并无直接操做本网站的内容，而是须要本网站上写js调用js文件中的函数引入的js文件才能起做用；因此应该理解为仍是本站的js操做本站的内容，至少是本站的js主动要求其余站的js处理本站的内容。

 

参考：

http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html