=Start=

缘由：

本来之前对Web安全就不是太了解，后来工作之后也一直都没有往这方面去深入学习、发展，所以对细节越来越模糊了，最近想着在有时间的时候不断去补习有所欠缺或是比较感兴趣的知识点。苦练基本功！

正文：

参考解答：

1、什么是同源策略？

同源策略（Same Origin Policy）是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说 Web 是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现。

它的核心就在于它认为自任何站点装载的信赖内容是不安全的。当被浏览器半信半疑的脚本运行在沙箱时，它们应该只被允许访问来自同一站点的资源，而不是那些来自其它站点可能怀有恶意的资源。

所谓同源是指：域名、协议、端口相同。比如：

#	URL	是否同源	备注
1	http://store.company.com/dir2/other.html	base
2	http://store.company.com/dir/inner/another.htm|	是
3	https://store.company.com/secure.html	否	协议不同
4	http://store.company.com:81/dir/etc.html|	否	端口不同
5	http://news.company.com/dir/other.html	否	host不同

对于 about:blank和 javascript:这种特殊的URL，他们的源应当是继承自加载他们的页面的源，他们本身并没有『源』的概念。

2、浏览器为什么要设置同源策略？

同源政策的目的，是为了保证用户信息的安全，防止恶意的网站窃取数据。

设想这样一种情况：A网站是一家银行，用户登录以后，又去浏览其他网站。如果其他网站可以读取A网站的 Cookie，会发生什么？

很显然，如果 Cookie 包含隐私（比如存款总额），这些信息就会泄漏。更可怕的是，Cookie 往往用来保存用户的登录状态，如果用户没有退出登录，其他网站就可以冒充用户，为所欲为。因为浏览器同时还规定，提交表单不受同源政策的限制。

由此可见，”同源政策”是必需的，否则 Cookie 可以共享，互联网就毫无安全可言了。

3、浏览器同源策略的限制

除了 cookie 的访问受到同源策略的限制外，还有一些操作也同样受到同源策略的限制：

(1) 无法读取非同源网页的 Cookie 、sessionStorage 、localStorage 、IndexedDB

(2) 无法读写非同源网页的 DOM

(3) 无法向非同源地址发送 AJAX请求（可以发送，但浏览器会拒绝响应而报错）

虽然这些限制是必要的，但是有时很不方便，合理的用途也受到影响。

4、跨域的一些方法整理

五种前端跨域方法

1、JSONP

JSONP(json with padding) ，利用了 <script> 标签能跨域的特性。需要前端和后端约定好一个函数名，当前端请求后端时，返回一段 JS。这段 JS 调用了之前约定好的回调函数，并将数据当作参数传入，完成数据的跨域传递。

这种方式有几个安全问题：

• 一是接收请求的 api 页面是属于公共使用的那还好，如果是内部私用就会造成一个用户信息泄露的问题；
• 二是如果 callback 参数的内容是一段 js 代码，当后端没有过滤或者过滤不严时，可能会出现 XSS 问题；三是有可能会出现 SOME 漏洞。

2、document.domain

这种方式有些局限性，只能在顶级域名相同的两个页面中跨域访问。通常情况下，在一个页面中内嵌一个不同域的 iframe，两个页面是无法相互访问的，所以多用于控制页面中内嵌的 iframe。然后再来说下 js 中的 document.domain 这个东西。这个东西会显示当前页面的域名。也可以设置，但有限制，只能设置成当前的域名或者顶级域名。如果设置为其他的域名则会报一个“参数无效”的错误。

3、window.name

关于 window.name 我们先来看这样一个场景，首先是 A 站：

window.name = 'A site data';
location.href = 'http://b.com';

设置完 window.name 后自动跳转到 B 站，此时我们在控制台里 alert 出 window.name ，发现还是我们在 A 站中设置的数据。可以看到如果在一个标签里跳转页面的话，我们的 window.name 是不会改变的。我们可以了利用这个特性进行跨域。顺便提一下，从页面内部打开的另一个页面会包含前一个页面的引用，这也是 target=”_blank” 漏洞的成因。

相同的技术也可以用在 iframe 的跨域数据传递中。

4、postMessage

postMessage 是 HTML5 时代新出现的 API。用于安全的进行跨域请求。从字面意思就可以想象，就是一个页面对另一个页面发消息来实现跨域通信。

5、browser SOP bug

虽然所有的浏览器都有同源策略，但是各家浏览器实现的方式也是各不相同。难免实现也会有漏洞。我们可以找出浏览器同源策略的漏洞来实现跨域访问。例如浏览器对 CSS（层叠样式表）的松散解析就会导致跨域bug的出现。

三种服务器跨域方法

1、反向代理服务器

由于服务器是可以跨域访问数据的。于是我们前端想要什么别的域的数据直接告诉后端服务器，让服务器帮我们去跨域读数据，获取到了再传给我们，这样前端也可以处理别的域内的数据了。也就是说，将其他域名的资源映射到你自己的域名之下，这样浏览器就认为他们是同源的。这就是反代服务器的原理，是不是非常简单。一般我们常常使用 nginx 来配置反向代理服务器。

2、CORS

暂略。

3、flash

了解太少，以后有机会再补充。

5、CORS的一些知识点

CORS（Cross-Origin Resource Sharing, 跨域资源共享）是HTML5的一个新特性，用于解决浏览器跨域网络资源访问，目前已经被所有浏览器支持，并被主流网站广泛部署使用。

随着Web应用的发展，Web开发者需要读取跨域网络资源内容(例如，电商网站想通过用户浏览器加载第三方快递网站的物流信息)，开发人员提出了一些临时折衷方案来满足需求，例如JSONP，但是这些折衷方案带来了许多安全问题。

于是W3C 设计了 CORS 协议标准，用于替代 JSONP，实现更安全规范地支持跨域网络资源共享。从2009年开始，CORS协议就已经被各大浏览器（如 Chrome， Firefox等）支持，目前已经被主流网站广泛部署使用。

CORS 的基本原理是，第三方网站服务器生成访问控制策略，指导用户浏览器放宽 SOP 的限制，实现与指定的目标网站共享数据。具体工作流程可分为三步：

1. 请求方脚本从用户浏览器发送跨域请求。浏览器会自动在每个跨域请求中添加Origin头，用于声明请求方的源。
2. 资源服务器根据请求中Origin头返回访问控制策略(Access-Control-Allow-Origin响应头)，并在其中声明允许读取响应内容的源。
3. 浏览器检查资源服务器在Access-Control-Allow-Origin头中声明的源，是否与请求方的源相符，如果相符合，则允许请求方脚本读取响应内容，否则不允许。

在CORS协议中，请求方还可以指示浏览器在跨域请求中是否带credentials（包括Cookie，TLS客户端证书和代理验证信息）。如果跨域请求中带了credentials，那么浏览器会检查资源服务器返回的响应头中Access-Control-Allow-Credentials头是否设置为true，如果是，则允许请求方读取响应内容，否则，不允许。

关于CORS其它的细节，读者可以阅读 CORS标准，这里不再详述。

参考链接：

• 再谈同源策略
  https://mp.weixin.qq.com/s/9liyeltutNgFKEZaUhpN_g
  https://mp.weixin.qq.com/s/IrWH0ebCNlt_6EiSOY9Kkg
• 同源策略与跨域请求
  https://mp.weixin.qq.com/s/bSXhcnQk_2Omv89rVefocQ
• 浏览器同源策略及跨域的解决方法
  https://mp.weixin.qq.com/s/yk8H7ko2wkUBhsAth81r7g
• 浏览器同源政策及其规避方法
  http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html
• 跨域资源共享 CORS 详解
  http://www.ruanyifeng.com/blog/2016/04/cors.html
• =
• 绕过浏览器SOP，跨站窃取信息：CORS配置安全漏洞报告及最佳部署实践#超赞超详细！
• HTTP访问控制（CORS）
  https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Access_control_CORS
• 正确面对跨域，别慌 #不错
  https://juejin.im/post/5a2f92c65188253e2470f16d

=END=