跨域问题

ゝ一世哀愁。 2022-01-14 13:01 328阅读 0赞

确实，我们这种搬砖工人就是为了混口饭吃嘛，好好的调个接口告诉我跨域了，这种阻碍我们轻松搬砖的事情真恶心！为什么会跨域？是谁在搞事情？为了找到这个问题的始作俑者，请点击[浏览器的同源策略][Link 1]。  
       这么官方的东西真难懂，没关系，至少你知道了，因为浏览器的同源策略导致了跨域，就是浏览器在搞事情。  
所以，浏览器为什么要搞事情？就是不想给好日子我们过？对于这样的质问，浏览器甩锅道：“同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。” 这么官方的话术真难懂，没关系，至少你知道了，似乎这是个安全机制。  
       所以，究竟为什么需要这样的安全机制？这样的安全机制解决了什么问题？别急，让我们继续研究下去。

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

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

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

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

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

这就是传说中的CSRF（跨站请求伪造）攻击[浅谈CSRF攻击方式][CSRF]。CSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出CSRF漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型的BLOG网站），YouTube和百度HI......而现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称CSRF为“沉睡的巨人”。

**下图简单阐述了CSRF攻击的思想：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70][]

看了这波CSRF攻击我在想，即使有了同源策略限制，但cookie是明文的，还不是一样能拿下来。于是我看了一些cookie相关的文章[Cookie/Session的机制与安全][Cookie_Session]、[Cookief防劫持][Cookief]，知道了服务端可以设置httpOnly，使得前端无法操作cookie，如果没有这样的设置，像XSS攻击就可以去获取到cookie。

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

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

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

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

## 跨域正确的打开方式 ##

经过对同源策略的了解，我们应该要消除对浏览器的误解，同源策略是浏览器做的一件好事，是用来防御来自邪门歪道的攻击，但总不能为了不让坏人进门而把全部人都拒之门外吧。没错，我们这种正人君子只要打开方式正确，就应该可以跨域。

**解决跨域问题的方案：**

目前比较常用的跨域解决方案有3种：

*  **Jsonp**
    
    最早的解决方案，利用script标签可以跨域的原理实现。限制：
    
     *  需要服务的支持
     *  只能发起GET请求
 *  **nginx反向代理**
    
    思路是：利用nginx把跨域反向代理为不跨域，支持各种请求方式
    
    缺点：需要在nginx进行额外配置，语义不清晰
 *  **CORS**
    
    规范化的跨域请求解决方案，安全可靠。优势：
    
     *  在服务端进行控制是否允许跨域，可自定义规则
     *  支持各种请求方式
    
    缺点：
    
     *  会产生额外的请求

## cors解决跨域 ##

CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）。它允许浏览器向跨源服务器，发出[`XMLHttpRequest`][XMLHttpRequest]请求，从而克服了AJAX只能[同源][Link 2]使用的限制。CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。

*  浏览器端：
    
    目前，所有浏览器都支持该功能（IE10以下不行）。整个CORS通信过程，都是浏览器自动完成，不需要用户参与。
 *  服务端：
    
    CORS通信与AJAX没有任何差别，因此你不需要改变以前的业务逻辑。只不过，浏览器会在请求中携带一些头信息，我们需要以此判断是否允许其跨域，然后在响应头中加入一些信息即可。这一般通过过滤器完成即可。

浏览器会将ajax请求分为两类，其处理方案略有差异：**简单请求、特殊请求**。

### 简单请求 ###

只要同时满足以下两大条件，就属于简单请求。：

（1) 请求方法是以下三种方法之一：

*  HEAD
 *  GET
 *  POST

（2）HTTP的头信息不超出以下几种字段：

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

当浏览器发现发起的ajax请求是简单请求时，会在请求头中携带一个字段：`Origin`. Origin中会指出当前请求属于哪个域（协议+域名+端口）。服务会根据这个值决定是否允许其跨域。

如果服务器允许跨域，需要在返回的响应头中携带下面信息：

> Access-Control-Allow-Origin: http://manage.leyou.com  
> Access-Control-Allow-Credentials: true  
> Content-Type: text/html; charset=utf-8

*  Access-Control-Allow-Origin：可接受的域，是一个具体域名或者\*（代表任意域名）
 *  Access-Control-Allow-Credentials：是否允许携带cookie，默认情况下，cors不会携带cookie，除非这个值是true

> 有关cookie：

要想操作cookie，需要满足3个条件：

*  服务的响应头中需要携带Access-Control-Allow-Credentials并且为true。
 *  浏览器发起ajax需要指定withCredentials 为true
 *  响应头中的Access-Control-Allow-Origin一定不能为\*，必须是指定的域名

### 特殊请求 ###

不符合简单请求的条件，会被浏览器判定为特殊请求,，例如请求方式为PUT。

**预检请求**

特殊请求会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的`XMLHttpRequest`请求，否则就报错。

一个“预检”请求的样板：

> OPTIONS /cors HTTP/1.1  
> Origin: http://manage.leyou.com  
> Access-Control-Request-Method: PUT  
> Access-Control-Request-Headers: X-Custom-Header  
> Host: api.leyou.com  
> Accept-Language: en-US  
> Connection: keep-alive  
> User-Agent: Mozilla/5.0...

与简单请求相比，除了Origin以外，多了两个头：

*  Access-Control-Request-Method：接下来会用到的请求方式，比如PUT
 *  Access-Control-Request-Headers：会额外用到的头信息

> 预检请求的响应

服务的收到预检请求，如果许可跨域，会发出响应：

> HTTP/1.1 200 OK  
> Date: Mon, 01 Dec 2008 01:15:39 GMT  
> Server: Apache/2.0.61 (Unix)  
> Access-Control-Allow-Origin: http://manage.leyou.com  
> Access-Control-Allow-Credentials: true  
> Access-Control-Allow-Methods: GET, POST, PUT  
> Access-Control-Allow-Headers: X-Custom-Header  
> Access-Control-Max-Age: 1728000  
> Content-Type: text/html; charset=utf-8  
> Content-Encoding: gzip  
> Content-Length: 0  
> Keep-Alive: timeout=2, max=100  
> Connection: Keep-Alive  
> Content-Type: text/plain

除了`Access-Control-Allow-Origin`和`Access-Control-Allow-Credentials`以外，这里又额外多出3个头：

*  Access-Control-Allow-Methods：允许访问的方式
 *  Access-Control-Allow-Headers：允许携带的头
 *  Access-Control-Max-Age：本次许可的有效时长，单位是秒，**过期之前的ajax请求就无需再次进行预检了**

如果浏览器得到上述响应，则认定为可以跨域，后续就跟简单请求的处理是一样的了。

### 实现非常简单 ###

虽然原理比较复杂，但是前面说过：

*  浏览器端都有浏览器自动完成，我们无需操心
 *  服务端可以通过拦截器统一实现，不必每次都去进行跨域判定的编写。

**事实上，SpringMVC已经帮我们写好了CORS的跨域过滤器：CorsFilter ,内部已经实现了刚才所讲的判定逻辑，我们直接用就好了。**

### **实例：** ###

在`leyou-gateway`中编写一个配置类，并且注册CorsFilter：

import org.springframework.context.annotation.Bean;
    import org.springframework.context.annotation.Configuration;
    import org.springframework.web.cors.CorsConfiguration;
    import org.springframework.web.cors.UrlBasedCorsConfigurationSource;
    import org.springframework.web.filter.CorsFilter;
    
    @Configuration
    public class GlobalCorsConfig {
        @Bean
        public CorsFilter corsFilter() {
            //1.添加CORS配置信息
            CorsConfiguration config = new CorsConfiguration();
            //1) 允许的域,不要写*，否则cookie就无法使用了
            config.addAllowedOrigin("http://manage.leyou.com");
            //2) 是否发送Cookie信息
            config.setAllowCredentials(true);
            //3) 允许的请求方式
            config.addAllowedMethod("OPTIONS");
            config.addAllowedMethod("HEAD");
            config.addAllowedMethod("GET");
            config.addAllowedMethod("PUT");
            config.addAllowedMethod("POST");
            config.addAllowedMethod("DELETE");
            config.addAllowedMethod("PATCH");
            // 4）允许的头信息
            config.addAllowedHeader("*");
    
            //2.添加映射路径，我们拦截一切请求
            UrlBasedCorsConfigurationSource configSource = new UrlBasedCorsConfigurationSource();
            configSource.registerCorsConfiguration("/**", config);
    
            //3.返回新的CorsFilter.
            return new CorsFilter(configSource);
        }
    }

[Link 1]: https://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy
[CSRF]: http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70]: /images/20220114/b6a6ce24159f42ab87f8d8b2b6257161.png
[Cookie_Session]: https://harttle.land/2015/08/10/cookie-session.html
[Cookief]: https://blog.csdn.net/adley_app/article/details/80734602
[XMLHttpRequest]: http://www.ruanyifeng.com/blog/2012/09/xmlhttprequest_level_2.html
[Link 2]: http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html