如何解决 Chrome Cookie Same-Site 跨域问题

Jeremy23
4,949 阅读9分钟

1. 前言

最近在本地开发环境测试公司系统时，遇到了跨域问题，导致无法登录获取用户权限。原本只要是本地浏览器存储了目标服务器的cookie 信息就可以发送跨域请求，但奇怪的是，已经通过开启 CORS 同源请求的方式获取到了 cookie，在本地开发环境启动的系统依然出现了跨域情况，检查发现请求根本没有自动携带 cookie。为什么开启了 CORS，还是会出现跨域的问题呢？

文章大纲

  • 分析问题

  • 为什么会有跨域问题

  • 如何解决跨域问题

  • 为什么开启 CORS，还会出现跨域

  • 解决问题

  • 浏览器关闭 Same-Site

  • 使用第三方代理

2. 分析问题

2.1 为什么会有跨域问题

跨域本质上是 浏览器实现**同源策略（Same Origin Policy）**的一种安全手段。对于同源的定义，url 协议（protocol）、端口（port）、主机（host 域名）完全相同称为同源站点。同源策略限制了两个不同源站点的资源访问，比如前端想通过 XMLHttpRequest 将站点数据发送给不同源站点，就会产生跨域问题。

比如 A 源为：http://store.company.com/dir/page.html，下列与 B 源 的对比。引用自 MDN Definition of an origin

| URL | Outcome | Reason |

| :------------------------------------------------ | :---------- | :----------------------------------------------- |

| http://store.company.com/dir2/other.html | Same origin | Only the path differs |

| http://store.company.com/dir/inner/another.html | Same origin | Only the path differs |

| https://store.company.com/page.html | Failure | Different protocol |

| http://store.company.com:81/dir/page.html | Failure | Different port (http:// is port 80 by default) |

| http://news.company.com/dir/page.html | Failure | Different host |

而本地前端服务 http://localhost:9096 与服务端 http://api.backend.com 是不同源的，存在跨域资源访问限制问题。

2.2 如何解决跨域问题

解决跨域问题，有很多种方式，比如使用 JSONP、CORS、Proxy 等方案。在公司的项目中，使用了 CORS 方案。

CORS 跨域资源共享是为了解决同源策略的网络层面限制而引入的，它是一种基于 HTTP 头的机制，该机制通过允许服务器标示除了它自己以外的其他 origin（域，协议和端口），这样会浏览器可以访问加载这些资源。

如何开启呢，比如一个登录 login 接口简单请求，浏览器发出的请求信息会添加 origin 字段，Origin字段用来说明，本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。


GET /cors HTTP/1.1

+ Origin: http://api.backend.com

Host: localhost:9096

Accept-Language: zh-CN,zh

Connection: keep-alive

User-Agent: Mozilla/5.0...

...

如果Origin指定的域名在许可范围内，服务器会设置响应头 Access-Control-Allow-Origin ，浏览器会检查这个字段，从而让 XMLHttpRequest 正常获得结果，否则，就会抛出错误。


+ Access-Control-Allow-Origin: http://localhost:9096

Set-cookie: token=xxxx; Path=xxx

同时，服务器会通过 Session-Cookie 机制维护用户的登录状态，从而使用 Set-Cookie 告诉浏览器中写入 Cookie。

登录成功后，客户端再次发送一个 getUser 接口用于获取用户权限信息，要携带之前的 Cookie 发送给服务端。

由于 CORS 请求默认不发送 Cookie 和 HTTP 认证信息。所以要把 Cookie 发送到服务器，需要 ajax 请求中开发 withCredentials 属性 为 true，并且服务端要指定 Access-Control-Allow-Credentials 字段：


+ Access-Control-Allow-Credentials: true

并且Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。这样，就可以实现携带 Cookie 正常访问不同源的服务端资源了。

2.3 为什么开启 CORS，还会出现跨域

通过查看浏览器的 Chrome Network 发现，登录成功后，getUser 接口发送的浏览器请求没有正常携带 Cookie 字段。关于 cookie 无法被携带问题，有不少排查的方向，

  • 浏览器是可以禁用 Cookie 的 chrome://settings/cookies?search=cookie

  • 浏览器的插件导致，可以考虑使用无痕模式测试

  • 是否开启了某些工具模拟请求，网络设置问题

  • 是否是 Cookie 的属性设置问题，比如 domain、path、失效时间等。

  • ...

经过仔细排查后发现这是因为浏览器设置的 Cookie 的 Same-Site 属性问题，导致 Cookie 无法被正常携带。

image.png

Cookie 的 Same-Site 属性是为了防止（CSRF-Cross-Site-Request-Forgery）跨站请求伪造攻击，CSRF 是指在受害者访问一个网站时，其 Cookie 还没有过期的情况下，攻击者伪造一个链接地址发送受害者并欺骗让其点击，从而获取用户信息。

Same-Site 名为同站，那它跟跨站、跨域有什么区别呢，理解它们的区别有利于我们更好的理解 Cookie 的 Same-Site 属性。

2.3.1 同站（Same-Site）、跨站（Cross-Site）与跨域（Cross-Origin）的区别

跨域

本质上是 浏览器实现**同源策略（Same Origin Policy）**的一种安全手段。对于同源的定义，url 协议（protocol）、端口（port）、主机（host 域名）完全相同称为同源站点。

同站与跨站

只要两个 URL 的eTLD+1 相同即是同站，否则为跨站，不需要考虑协议和端口。

eTLD: (effective top-level domain) 有效顶级域名，注册于 Mozilla 维护的公共后缀列表（Public Suffix List）中,如 .com、.org 、.com 等

eTLD+1: 有效顶级域名 + 二级域名，如 taobao.com，baidu.com，sugarat.top

参考MDN developer.mozilla.org/en-US/docs/…

2.3.2 Cookie 的 Same-Site

大部分网站使用了 Cookie 来存储登录状态，保护 Cookie 不被三方站点利用尤为重要，我们可以合理设置 Cookie 的 Samesite 属性值防御 CSRF 攻击。

  • strict：严格校验，严格校验站点是否为同源

  • lax：较宽松校验，在跨站点的情况下，从第三方网站打开链接，get 方式提交表单都会携带 cookie，

但如果在第三方站点中使用了 post 方法，或者通过 img，iframe 等标签加载的 url，会禁止 cookie 发送

  • none：不校验第三方站点是否为同源或同一站点，任何情况下都会发送 cookie

3. 解决问题

3.1 浏览器关闭 Cookie 的 Same-Site

我们可以通过手动关闭 Cookie 的 Same-Site，这样就正常携带 Cookie 给服务端了。在 Chrome 浏览器中可以输入 chrome://flags/

把 SameSite by default Cookie 和 Cookies without SameSite must be secure 禁用掉。

image

  • SameSite by default Cookie 禁用或开启 SameSite Cookie 的规则

  • Cookies without SameSite must be secure ：当没有设置 SameSite 属性或者设为 None 的时候，开启这个规则就要求跨站的前后端数据通信必须是 https 协议。

在 91 版本以前，是可以这样做的。仔细发现浏览器 Chrome 自动升级到了 91 版本，91 版本不再给手动关闭了。

image

如果想让后端设置响应头关闭，通过设置 Set-Cookie 时设置 Same-Site 属性为 none ，但是这种做法要 https 协议才支持，必须设置 Secure 属性。


Set-Cookie: widget_session=abc123; SameSite=None; Secure

既然不能手动设置了，还有其他的方案吗？

方案一：本地开发暂时不升级到 91 版本了。

方案二：通过反向代理解决这个问题。

接下来具体说说方案二。

3.2 使用第三方代理

在使用代理解决 Cookie 携带问题前，先要搞懂什么是正向代理和反向代理。

正向代理与反向代理的区别是他们提供的服务对象不同，

  • 正向就是对服务获取方服务的，表现为在客户端的出口位置，主要解决客户端的问题（比如科学上外网）

  • 反向就是对服务提供方服务的，表现为在服务端的网络入口位置，主要解决服务端的问题（负载均衡）

来自知乎某图 www.zhihu.com/question/24…

3.2.1 正向代理

举个例子，没有代理的情况下，日常 git clone 仓库常常 443 错误，这是 https 开放的默认端口。


git clone https://github.com/alexjoverm/typescript-library-starter.git ts-axios

Cloning into 'ts-axios'...

fatal: unable to access 'https://github.com/alexjoverm/typescript-library-starter.git/': LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to github.com:443

image


# 使用socks5协议

HTTP_PROXY="socks5://127.0.0.1:1086" HTTPS_PROXY="socks5://127.0.0.1:1086" git clone https://github.com/alexjoverm/typescript-library-starter.git ts-axios

# 使用http协议

HTTP_PROXY="http://127.0.0.1:1087" HTTPS_PROXY="http://127.0.0.1:1087" git clone https://github.com/alexjoverm/typescript-library-starter.git ts-axios

正向代理：客户端 --- 代理服务器 --- 目标服务器。这样就可以正常下载仓库了。

3.2.2 反向代理

除了使用反向代理作负载均衡外，还可以使用反向代理解决跨站携带 Cookie 的问题，核心思路就是在前端本地使用代理服务器，整个数据的传递方式是 目标服务器---代理服务器---浏览器，而本地代理服务器与本地浏览器是属于同站，不存在跨站问题，而服务器与服务器之间传递数据没有同源策略的限制，并不会存在跨域行为，代理服务器与目标服务器之间能正常转发 Cookie， 浏览器就能正常携带 Cookie 给目标服务器了。

如果你是 Vue 项目的话，一般是通过 Vue-Cli 脚手架搭建，要使用实现代理服务，可以直接在 vue.config.js 文件对应 webpack 的 w配置增加 devServer.proxy 配置，值为要被代理的目标地址，


module.exports = {

devServer: {

port: 9000

proxy: 'http://backend.com:4000'

}

}

前端根据 devServer.port 修改资源请求的地址为对应的 localhost + port 的形式即可，也就是说前端直接请求代理服务器地址即可，http://localhost:9000，这样前端发送请求，由于与代理服务器是同站，浏览器就会携带上 Cookie，Cookie 经过代理服务器进行转发给目标服务器，这样就可以正常维持登录状态了。

image.png

除了上面的方式外，你也可以使用 node 构建一个简单的代理服务器


const http = require("http");

const httpProxy = require("http-proxy"); // 通过 http-proxy 实现代理功能

const proxy = httpProxy.createProxyServer();

proxy.on("error", function(err, req, res) {

res.end();

});

const proxy_server = http.createServer(function(req, res) {

proxy.web(req, res, {

target: "http://backend.com:18080" // 目标服务器

});

});

proxy_server.listen(8080, function() { // 代理服务器监听的端口

console.log("proxy server is running");

});

如果在生产环境上，前端应用与后端应用不在同一个服务器上，还可以使用 nginx 进行代理转发。

  1. 把访问 http://代理服务器地址:9001/edu 的请求转发到 http://目标服务器1:8080

  2. 把访问 http://代理服务器地址:9001/vod 的请求转发到 http://目标服务器2:8081


server {

listen 9001; // 代理服务器端口

server_name xxx.xxx // 代理服务器域

;

location ~ /edu/ {

proxy_pass http://目标服务器域1:8080;

}

location ~ /vod/ {

proxy_pass http://目标服务器域2:8081;

}

}

4. 小结

对于 Cookie Same-Site 的处理，本质上还是解决跨域的问题，离不开业界的方案，比如 CORS、设置代理，还可以通过 token 认证方式绕过这种处理，前端拿到服务端的 token 保存到本地，每次请求时都写到请求头里，这也是一种方案。

参考资料

avatar
文章
阅读
粉丝