浏览器同源策略理解

一、背景说明

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

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

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

 

二、同源策略

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