CORS（跨域资源共享）

最新推荐文章于 2024-08-18 20:34:59 发布
最新推荐文章于 2024-08-18 20:34:59 发布
阅读量539 收藏
点赞数
分类专栏： 网络 文章标签： http CORS
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/letterTiger/article/details/105351139
版权

CORS（跨域资源共享）使用额外的HTTP头部来告诉浏览器，允许运行在origin(domain)上的Web应用访问来自不同源服务器上的指定资源。

浏览器访问一个web应用，这个web应用会发很多的跨域请求，例如加载不同源的JS/CSS脚本，或者加载不同源图片等。但是并没有发现请求的异常，这些资源是可以正常返回的。而通过JS发送的跨域HTTP请求却时常得到错误，所以跨域请求很常见，但是浏览器对于请求跨域的限制却只存在于脚本发送的HTTP请求（Ajax/Fetch）。

同源限制在安全上是有其必要性的，例如可以很轻松规避CSRF攻击。

通过上面的描述可以看出来同源策略的限制存在于浏览器端，而CORS策略用额外的HTTP请求头字段来告诉浏览器，该资源是允许被当前域上的web应用跨域访问的。

CORS的具体步骤

那么具体CORS是怎么做的呢？

  1. 浏览器察觉请求跨域没有发起请求？
  2. 浏览器发起跨域请求没有正常返回结果？

上面说到“通过额外的HTTP头告诉浏览器源上的web应用被允许访问来自不同源服务器上的指定资源”。告诉浏览器的自然是通过服务端的响应携带的额外的HTTP头，所以可以看出来请求是发送了的。那么服务端是携带了标识当前源允许访问的该资源的HTTP头？如果允许的话自然是请求一切正常，不允许的话浏览器则会报错并且不会将请求结果返回给请求的发起方，也就是Ajax/Fetch代码，并且代码中获取不到是哪一步出了错只能在浏览器中看到错误日志（为了安全）。

那么就只是这样吗？跨域请求失败是因为浏览器正常发送了请求，服务端正常响应了请求，然后浏览器发觉响应头中没有允许跨域的标识，然后拦截返回结果并报错。

并不完全是这样，这只是CORS的一部分，这部分被称为简单请求。

既然有简单请求就有非简单请求。非简单请求的具体步骤和上面描述的简单请求很不一样，会在发送真正的请求之前发送一个预检请求（preflight request）询问服务端是否允许当前源跨域访问该资源，允许则继续发送真正的请求，否则直接报错。

所以上面的两种做法都被应用到CORS策略中：一种是拦截请求的返回结果，一种是不发送真正的跨域请求。

简单请求

简单请求并不会发送预检请求，而是直接发送真正的请求。简单请求必须要全部满足下面的条件：

  • 使用下列方法之一：
    • GET
    • HEAD
    • POST
  • 不得人为设置该集合之外的其他首部字段。该集合为：
    • Accep
    • Accept-Language
    • Content-Language
    • Content-Type（需要注意额外的限制）
    • DPR
    • Downlink
    • Save-Data
    • Viewport-Width
    • Width
  • Content-Type 的值仅限于下列三者之一：（这个集合中没有application/json）
    • text/plain
    • multipart/form-data
    • application/x-www-form-urlencoded
  • 请求中的任意XMLHttpRequestUpload`对象均没有注册任何事件监听器；XMLHttpRequestUpload对象可以使用 XMLHttpRequest.upload 属性访问。
  • 请求中没有使用ReadableStream对象。

下面我们将从源http://dev.jd.com:9091访问http://dev.jd.com:9090的资源。

如果没有使用CORS显然会被浏览器的同源策略限制从而报错，如下：

在这里插入图片描述

分别查看请求头：

GET /corsget HTTP/1.1
Host: dev.jd.com:9090
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1
Accept: */*
Origin: http://dev.jd.com:9091
Referer: http://dev.jd.com:9091/index.html
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

通过请求头可以看出来其中包含了很多简单请求定义的字段以外的字段，但是却并没有触发预检请求，这是因为这些头字段并不是人为设置的。

响应头：

HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 16
ETag: W/"10-oV4hJxRVSENxc/wX8+mA4/Pe4tA"
Date: Mon, 06 Apr 2020 09:45:36 GMT
Connection: keep-alive

修改服务端程序，让响应头带上标识，告诉浏览器允许源http://dev.jd.com:9091上的web应用访问不同源（http://dev.jd.com:9090）上的资源/corsget。

请求头同上，响应头如下：

HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Content-Length: 16
ETag: W/"10-oV4hJxRVSENxc/wX8+mA4/Pe4tA"
Date: Mon, 06 Apr 2020 09:58:06 GMT
Connection: keep-alive

可以看到多了一个Access-Control-Allow-Origin这个字段，该字段表示被允许访问该资源的不同源，这里指定了*表示告诉浏览器任何源都可以访问该资源。

通过观察还可以发现请求头中有字段Origin正好对应的是就是http://dev.jd.com:9091web应用所在的源。

在这里插入图片描述

非简单请求

上面简单请求的条件只要有一个没有满足就会变成非简单请求。非简单请求会首先发送一个预检请求询问服务端是否允许跨域，服务端允许后才会发送真正的请求。

注：chrome的network面板中看不到预检请求，可以查看 chrome://flags/#out-of-blink-cors 配置，改成 disabled 后重启 Chrome ，或者换个浏览器Firefox是可以看到的，目前是74.0版本。

预检的请求头：

OPTIONS /corsget HTTP/1.1
Host: dev.jd.com:9090
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Access-Control-Request-Method: GET
Access-Control-Request-Headers: content-type
Origin: http://dev.jd.com:9091
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1
Accept: */*
Referer: http://dev.jd.com:9091/index.html
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

通过人为修改请求头的content-type为application/json将原本的简单请求变成了非简单请求，因为application/json并不在简单请求的三种content-type中。

这样就需要首先发送一个预检请求。

可以看到请求头中有如下字段：

  1. Access-Control-Request-Method: GET

    用于预检请求，将实际发送的请求的method告知服务器

  2. Access-Control-Request-Headers: content-type

    用于预检请求，将实际发送的请求头（不满足简单请求条件）告知给服务器

  3. Origin: http://dev.jd.com:9091

    告诉服务器请求源

预检响应头：

HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: OPTIONS
Access-Control-Allow-Headers: Content-Type
Content-Type: text/html; charset=utf-8
Content-Length: 0
ETag: W/"0-2jmj7l5rSw0yVb/vlWAYkK/YBwk"
Date: Mon, 06 Apr 2020 10:57:40 GMT
Connection: keep-alive

可以看到如下字段：

  1. Access-Control-Allow-Origin: *

    告诉浏览器任何源都可访问该资源

  2. Access-Control-Allow-Methods: OPTIONS
    告诉浏览器options被允许跨域访问该资源。options并不在简单请求被允许的method中，但是预检请求确是options，所以需要指定options被允许。

  3. Access-Control-Allow-Headers: Content-Type

    告诉浏览器三个Content-Type值之外的Content-Type值被允许跨域访问该资源。因为application/json并不在简单请求的三个content-type中。

然后发送实际的get请求，请求头如下：

GET /corsget HTTP/1.1
Host: dev.jd.com:9090
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Origin: http://dev.jd.com:9091
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1
Content-Type: application/json
Accept: */*
Referer: http://dev.jd.com:9091/index.html
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

实际请求的响应头如下：

HTTP/1.1 200 OK
X-Powered-By: Express
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Content-Length: 16
ETag: W/"10-oV4hJxRVSENxc/wX8+mA4/Pe4tA"
Date: Mon, 06 Apr 2020 10:57:40 GMT
Connection: keep-alive

可以看到实际请求的响应头中并没有复杂的访问控制类型的HTTP头，只有一个Access-Control-Allow-Origin: *。在实际请求的响应头中这个字段是必须的，如果没有这个头部即使预检通过了，实际发送的请求还是会失败，返回的结果还是会被浏览器拦截，并不会返回给脚本，并报错。

在这里插入图片描述

跨域请求和凭证

Ajax和Fetch的跨域请求默认不会携带凭证。可以通过Ajax/Fetch的设置让发送请求的时候带上凭证，但是如果服务端并不允许携带凭证的跨域请求，那么理所当然的跨域请求会失败。

在这里插入图片描述
Ajax: xhr.withCredentials = true

Fetch: fetch(url, {credentials: 'include', mode: 'cors'})

当服务端设置 Access-Control-Allow-Credentials: true 允许跨域请求携带凭证的时候对于Access-Control-Allow-Origin还有一个限制，就是值不能为*。

在这里插入图片描述
那么我们就需要在后端设置上指定允许携带凭证跨域的源，如果有多个怎么办呢？因为Access-Control-Allow-Origin这个字段并不能设置多个值，可以通过代码获取请求头的Origin来判断是否允许获取该资源，允许的话将Origin值设置给响应的HTTP头字段Access-Control-Allow-Origin即可。
在这里插入图片描述
仔细观察就可以发现Access-Control-Allow-Credentials: true这个响应头在预检和实际请求的响应头中被返回了两次（一次都不能少，否则会报错，一样是跨域错误），但是之前设置的Access-Control-Allow-Headers: Content-Type只有在预检的时候才会被返回。

其实关于Access-Control的HTTP头还有一个是控制预检请求的缓存时间的，就是Access-Control-Max-Age单位是秒。

所以初步猜测Access-Control-Allow-Credentials这个响应头并不能被缓存？

问题：

脚本会发送跨域请求，Origin指向的是HTML所在源还是脚本所在源呢？

参考：

  1. HTTP访问控制（CORS）
  2. Server-Side Access Control
  3. Fetch
葡萄糖o_o
关注
专栏目录
实战分析和精华总结：CORS跨域资源共享漏洞数据劫持、复现、分析、利用及修复过程
代码讲故事
12-03 1581
实战分析和精华总结：CORS跨域资源共享漏洞数据劫持、复现、分析、利用及修复过程。 CORS跨域资源共享漏洞与JSONP劫持漏洞类似，都是程序员在解决跨域问题中进行了错误的配置。攻击者可以利用Web应用对用户请求数据包的Origin头校验不严格，诱骗受害者访问攻击者制作好的恶意网站，从而跨域获取受害者的敏感数据，包括转账记录、交易记录、个人身份证号信息、订单信息等等。
跨域问题及CORS机制
目尽地平线
08-25 2524
跨域 跨域是指一个资源请求与其不在同一个域（源）的资源，不在同一个域（源）是指两个域的协议、域名或端口不同。 同源策略 出于安全考虑，浏览器制定了同源策略， 限制了某些跨域请求。同源策略是跨域问题产生的根源。但是，同源策略并没有限制所有的跨域请求，比如浏览器不限制加载嵌在标签中跨域的js文件。 跨域资源共享（CORS） 跨域资源共享（CORS）是浏览器提供的一种跨域协商机制，让前后端
跨域资源共享cors
最新发布
weixin_42564451的博客
08-18 423
浏览器为了安全起见，遵循同源策略（Same-origin policy），即只有当请求的源（协议、域名、端口）与资源所在的源完全相同时，才允许进行交互。是一种机制，用于放宽浏览器的同源策略，使得一个域可以访问另一个域的数据。：对于不符合简单请求条件的请求，浏览器会自动发送一个预检请求（OPTIONS方法），以询问服务器是否允许实际请求。一个简单的GET请求可以直接发送到服务器，而一个包含自定义头部的POST请求则会先发送一个预检请求。的资源，如果没有CORS的支持，浏览器会阻止这个请求。
跨域资源共享（CORS）
weixin_45678402的博客
08-07 1474
CORS是一种基于HTTP头的机制，该机制通过允许服务器标示除了它自己以外的其他origin（域、协议和端口），这样浏览器可以访问加载这些资源。 跨域资源共享通过一种机制来检查服务器是否会允许要发送的真实请求；该机制通过浏览器发起一个到服务器托管的跨源资源的**“预检”请求**； 在预检中，浏览器发送的头中标示有HTTP方法和真实请求中用到的头； CORS请求中分为简单请求和非简单请求： 简单请求： 不会触发CORS预检请求； 简单请求的条件： GET、HEAD、POST方法 Content-Type
Cors跨域资源共享
pscool的博客
01-03 1256
cors跨域资源共享
CORS 跨域资源共享
sekever的博客
04-03 687
浏览器一般使用 CORS（跨域资源共享）来处理跨域问题。同源导致了不同源数据不能互相访问，而在开发中我们很多时候需要用第一个页面的脚本访问第二个页面里的数据，所以制定了一些允许跨域的策略。
你可能不知道的CORS跨域资源共享
10-17
CORS（跨域资源共享）是Web开发中解决跨域访问问题的一种机制，它允许浏览器在遵循同源策略的前提下，通过特定的HTTP头部与服务器通信，从而实现不同源之间的资源访问。这种机制是为了解决现代Web应用中由于同源策略...
CORS跨域资源共享漏洞
墨鱼菜鸡
01-16 199
目录 CORS跨域资源共享 简单跨域请求 非简单请求 CORS的安全问题 有关于浏览器的同源策略和如何跨域获取资源，传送门——>浏览器同源策略和跨域的实现方法 同源策略(SOP)限制了应用程序之间的信息共享，并且仅允许在托管应用程序的域内共享。这有效防止了系统机密信息的泄露。但与此同时，...
CORS跨域资源共享及解决方案.docx
10-26
### CORS跨域资源共享及其解决方案详解 #### 一、CORS跨域资源共享背景 在现代Web应用开发中，前后端分离已成为一种主流趋势。在这种模式下，前端负责展示逻辑，而后端处理业务逻辑与数据交互。然而，由于浏览器...
前后端交互跨域问题解决方案，跨域资源共享（CORS）
weixin_42615523的博客
08-03 4230
跨域资源共享（CORS） 普通跨域请求：只服务端设置Access-Control-Allow-Origin即可，前端无须设置，若要带cookie请求：前后端都需要设置。 需注意的是：由于同源策略的限制，所读取的cookie为跨域请求接口所在域的cookie，而非当前页。如果想实现当前页cookie的写入，可参考下文：七、nginx反向代理中设置proxy_cookie_domain 和 八、N...
跨域资源共享CORS
qq_42806915的博客
09-14 288
1. 同源政策 1.1 含义 1995年，同源政策由 Netscape 公司引入浏览器。目前，所有浏览器都实行这个政策。 最初，它的含义是指，A网页设置的 Cookie，B网页不能打开，除非这两个网页”同源”。所谓”同源”指的是”三个相同”。 协议相同 域名相同 端口相同 举例来说，http://www.example.com/dir/page.html这个网址，协议是http://...
CORS-跨域资源共享
Ciao's blog
11-12 558
项目搭建初期常见的跨域问题
使用 Express 写接口
weixin_43563864的博客
10-27 1435
1. 使用 Express 写接口 1.实例 // express.js const express = require('express') const app = express() const port = 80; // 配置解析表单数据的中间件 app.use(express.urlencoded({ extended: false })); const apiRouter = require('./14apiRouter'); // 把路由模块，注册到 app 上 app.use('/api',
cors跨域资源共享
07-28
CORS（Cross-Origin Resource Sharing）是一种机制，用于允许在一个域名下的Web应用程序访问另一个域名下的资源。默认情况下，浏览器会...希望这能解答你关于CORS跨域资源共享的问题！如果还有其他问题，请随时提问。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值