跨域问题

川长思鸟来 2022-03-12 06:27 326阅读 0赞

要解决跨域问题先来看看什么是同源策略。

### 同源策略 ###

如果两个页面的协议，端口（如果有指定）和域名都相同，则两个页面具有相同的源。

下表给出了相对`http://store.company.com/dir/page.html`同源检测的示例:

![crossDomain01.png][]

### 没有同源策略限制的两大危险场景 ###

浏览器是从两个方面去做这个同源策略的，一是针对接口的请求，二是针对Dom的查询。试想一下没有这样的限制上述两种动作有什么危险。

没有同源策略限制的接口请求

有一个小小的东西叫cookie大家应该知道，一般用来处理登录等场景，目的是让服务端知道谁发出的这次请求。如果你请求了接口进行登录，服务端验证通过后会在响应头加入Set-Cookie字段，然后下次再发请求的时候，浏览器会自动将cookie附加在HTTP请求的头字段Cookie中，服务端就能知道这个用户已经登录过了。知道这个之后，我们来看场景：

1.  你准备去清空你的购物车，于是打开了买买买网站，然后登录成功，一看，购物车东西这么少，不行，还得买多点。
2.  你在看有什么东西买的过程中，你的好基友发给你一个链接，一脸yin笑地跟你说：“你懂的”，你毫不犹豫打开了。
3.  你饶有兴致地浏览着，谁知这个网站暗地里做了些不可描述的事情！由于没有同源策略的限制，它向发起了请求！聪明的你一定想到上面的话“服务端验证通过后会在响应头加入Set-Cookie字段，然后下次再发请求的时候，浏览器会自动将cookie附加在HTTP请求的头字段Cookie中”，这样一来，这个不法网站就相当于登录了你的账号，可以为所欲为了！如果这不是一个买买买账号，而是你的银行账号，那……

这就是传说中的CSRF攻击浅谈CSRF攻击方式。

看了这波CSRF攻击我在想，即使有了同源策略限制，但cookie是明文的，还不是一样能拿下来。于是我看了一些cookie相关的文章聊一聊 cookie、Cookie/Session的机制与安全，知道了服务端可以设置httpOnly，使得前端无法操作cookie，如果没有这样的设置，像XSS攻击就可以去获取到cookieWeb安全测试之XSS；设置secure，则保证在https的加密通信中传输以防截获。

没有同源策略限制的Dom查询

1.有一天你刚睡醒，收到一封邮件，说是你的银行账号有风险，赶紧点进去改密码。你吓尿了，赶紧点进去，还是熟悉的银行登录界面，你果断输入你的账号密码，登录进去看看钱有没有少了。  
2.睡眼朦胧的你没看清楚，平时访问的银行网站是yinhang.com，而现在访问的是yinghang.com，这个钓鱼网站做了什么呢？

<table> 
 <tbody> 
  <tr> 
   <td> <pre>// HTML
&lt;iframe name="yinhang" src="www.yinhang.com"&gt;&lt;/iframe&gt;
// JS
// 由于没有同源策略的限制，钓鱼网站可以直接拿到别的网站的Dom
const iframe = window.frames['yinhang']
const node = iframe.document.getElementById('你输入账号密码的Input')
console.log(`拿到了这个${node}，我还拿不到你刚刚输入的账号密码吗`)
</pre> </td> 
  </tr> 
 </tbody> 
</table>

由此我们知道，同源策略确实能规避一些危险，不是说有了同源策略就安全，只是说同源策略是一种浏览器最基本的安全机制，毕竟能提高一点攻击的成本。其实没有刺不穿的盾，只是攻击的成本和攻击成功后获得的利益成不成正比。

### 同源策略限制下接口请求的正确打开方式 ###

CORS是一个W3C标准，全称是”跨域资源共享”（Cross-origin resource sharing）跨域资源共享 CORS 详解。看名字就知道这是处理跨域问题的标准做法。

服务端加上`Access-Control-Allow-Origin: *` 搞定。

### 同源策略限制下Dom查询的正确打开方式 ###

用这个，`window.postMessage()` 是HTML5的一个接口，专注实现不同窗口不同页面的跨域通讯。

[crossDomain01.png]: http://localhost:4000/2013/03/05/Cross-Domain/crossDomain01.png