跨域资源共享

于 2024-05-12 14:30:00 发布
阅读量1.3k 收藏 43
点赞数 51
文章标签： okhttp
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/A_991128a/article/details/138676603
版权

最近浏览器升级遇到了好几次由于新版跨域导致的各种问题。复习下相关知识。

什么是跨域

广义的跨域

1.) 资源跳转： A链接、重定向、表单提交
2.) 资源嵌入： <link>、<script>、<img>、<frame>等dom标签，还有样式中background:url()、@font-face()等文件外链
3.) 脚本请求： js发起的ajax请求、dom和js对象的跨域操作等

常说的跨域

览器同源策略限制的一类请求场景。

同源策略/SOP（Same origin policy）是一种约定，由Netscape公司1995年引入浏览器，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。

同源策略限制以下几种行为：

1.) Cookie、LocalStorage 和 IndexDB 无法读取
2.) DOM 和 Js对象无法获得
3.) AJAX 请求不能发送

常见跨域场景

URL说明是否允许通信
http://www.domain.com/a.js
http://www.domain.com/b.js 同一域名，不同文件或路径 允许
http://www.domain.com/lab/c.js

http://www.domain.com:8000/a.js
http://www.domain.com/b.js 同一域名，不同端口不允许
 
http://www.domain.com/a.js
https://www.domain.com/b.js同一域名，不同协议不允许
 
http://www.domain.com/a.js
http://192.168.4.12/b.js 域名和域名对应相同ip不允许
 
http://www.domain.com/a.js
http://x.domain.com/b.js 主域相同，子域不同 不允许
http://domain.com/c.js
 
http://www.domain1.com/a.js
http://www.domain2.com/b.js不同域名 不允许

跨域解决方案

1、 通过jsonp跨域

2、 document.domain + iframe跨域

3、 location.hash + iframe

4、 window.name + iframe跨域

5、 postMessage跨域

6、 跨域资源共享（CORS）

7、 nginx代理跨域

8、 nodejs中间件代理跨域

9、 WebSocket协议跨域

以上是之前常用的一些方式，后来浏览器开始了版本大爆发。这些知识有点跟不上了。Chrome 83 开发者工具支持了 COEP 和 COOP 的 debug，Firefox 74 支持了 CORP，加上之前熟悉的 CORS 和不熟悉的 CORB。CO* 家族繁荣壮大了。

熟悉又陌生的CO*家族

CORS（Cross-origin resource sharing）

先从这个家族最熟悉的开始

CORS是一个W3C标准，全称是"跨域资源共享"（Cross-origin resource sharing）。

CORS需要浏览器和服务器同时支持。目前，所有浏览器都支持该功能，IE浏览器不能低于IE10。

浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。

简单请求

简单请求为了兼容表单（form），因为历史上表单一直可以发出跨域请求。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简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段。用来说明，本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。

如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段（详见下文），就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。

如果Origin指定的域名在许可范围内，服务器返回的响应，会多出几个头信息字段。

Access-Control-Allow-Origin: http://api.alipay.com
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: FooBar
Content-Type: text/html; charset=utf-8

上面的头信息之中，有三个与CORS请求相关的字段，都以Access-Control-开头。

（1）Access-Control-Allow-Origin

该字段是必须的。它的值要么是请求时Ori``gin字段的值，要么是一个*，表示接受任意域名的请求。

（2）Access-Control-Allow-Credentials

该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下，Cookie不包括在CORS请求之中。设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。这个值也只能设为true，如果服务器不要浏览器发送Cookie，删除该字段即可。

（3）Access-Control-Expose-Headers

该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader('FooBar')可以返回FooBar字段的值。

非简单请求

预检请求

非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。

非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为"预检"请求（preflight）。

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。

var url = 'http://api.alipay.com/cors';
var xhr = new XMLHttpRequest();
xhr.open('PUT', url, true);
xhr.setRequestHeader('X-Custom-Header', 'value');
xhr.send();

上面代码中，HTTP请求的方法是PUT，并且发送一个自定义头信息X-Custom-Header。

浏览器发现，这是一个非简单请求，就自动发出一个"预检"请求，要求服务器确认可以这样请求。下面是这个"预检"请求的HTTP头信息。

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

"预检"请求用的请求方法是OPTIONS，表示这个请求是用来询问的。头信息里面，关键字段是Origin，表示请求来自哪个源。

除了Origin字段，"预检"请求的头信息包括两个特殊字段。

（1）Access-Control-Request-Method

该字段是必须的，用来列出浏览器的CORS请求会用到哪些HTTP方法，上例是PUT。

（2）Access-Control-Request-Headers

该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段，上例是X-Custom-Header。

预检请求的回应

服务器收到"预检"请求以后，检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，确认允许跨源请求，就可以做出回应。

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2020 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://api.alipay.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
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

上面的HTTP回应中，关键的是Access-Control-Allow-Origin字段，表示[http://api.alipay.com](http://api.alipay.com)可以请求数据。该字段也可以设为星号，表示同意任意跨源请求。

Access-Control-Allow-Origin: *

如果服务器否定了"预检"请求，会返回一个正常的HTTP回应，但是没有任何CORS相关的头信息字段。这时，浏览器就会认定，服务器不同意预检请求，因此触发一个错误，被XMLHttpRequest对象的onerror回调函数捕获。控制台会打印出如下的报错信息。

XMLHttpRequest cannot load http://api.alipay.com.
Origin http://api.bob.com is not allowed by Access-Control-Allow-Origin.

服务器回应的其他CORS相关字段如下。

Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 1728000

（1）Access-Control-Allow-Methods

该字段必需，它的值是逗号分隔的一个字符串，表明服务器支持的所有跨域请求的方法。注意，返回的是所有支持的方法，而不单是浏览器请求的那个方法。这是为了避免多次"预检"请求。

（2）Access-Control-Allow-Headers

如果浏览器请求包括Access-Control-Request-Headers字段，则Access-Control-Allow-Headers字段是必需的。它也是一个逗号分隔的字符串，表明服务器支持的所有头信息字段，不限于浏览器在"预检"中请求的字段。

（3）Access-Control-Allow-Credenti****als

该字段与简单请求时的含义相同。

（4）Access-Control-Max-Age

该字段可选，用来指定本次预检请求的有效期，单位为秒。上面结果中，有效期是20天（1728000秒），即允许缓存该条回应1728000秒（即20天），在此期间，不用发出另一条预检请求。

浏览器的正常请求和回应

一旦服务器通过了"预检"请求，以后每次浏览器正常的CORS请求，就都跟简单请求一样，会有一个Origin头信息字段。服务器的回应，也都会有一个Access-Control-Allow-Origin头信息字段。

下面是"预检"请求之后，浏览器的正常CORS请求。

PUT /cors HTTP/1.1
Origin: http://api.alipay.com
Host: api.alipay.com
X-Custom-Header: value
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

上面头信息的Origin字段是浏览器自动添加的。

下面是服务器正常的回应。

Access-Control-Allow-Origin: http://api.alipay.com
Content-Type: text/html; charset=utf-8

上面头信息中，Access-Control-Allow-Origin字段是每次回应都必定包含的。

withCredentials

上面说到，CORS请求默认不发送Cookie和HTTP认证信息。如果要把Cookie发到服务器，一方面要服务器同意，指定Access-Control-Allow-Credentials字段。

Access-Control-Allow-Credentials: true

另一方面，开发者必须在AJAX请求中打开withCredentials属性。

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

否则，即使服务器同意发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会处理。

但是，如果省略withCredentials设置，有的浏览器还是会一起发送Cookie。这时，可以显式关闭withCredentials。

xhr.withCredentials = false;

需要注意的是，如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。同时，Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。

CORB（Cross-Origin Read Blocking）

不知道大家在调试BUG的时候 有没有在控制台看到这么一条警告

Cross-Origin Read Blocking (CORB) blocked cross-origin response www.chromium.org/ with MIME type text/html. See www.chromestatus.com/… for more details.

印象中这个警告有好久了。一直没管。这次也查了下

先看下 给的文档

an algorithm by which dubious cross-origin resource loads may be identified and blocked by web browsers before they reach the web page.

浏览器在加载可以跨域资源时，在资源载入页面之前，对其进行识别和拦截的算法。

前置知识

进入正题之前先学习下一般不怎么接触的姿势。

www.bilibili.com/video/av181…

旁路攻击（side-channel attacks）

首先需要了解的是旁路攻击这个术语，关于术语本身的解释，可以去维基百科搜索。简单讲的话，就是从软件系统的物理实现层获取信息进行攻击的手段，软件系统在正常运行时，产生了一些边缘特征，这些特征可以体现一些隐私信息。

这么说可能略显抽象，就拿后文视频链接中列举的例子说明一下，假设小 A 的账户密码是 gyease，小 B 想破解小 A 的密码，他可以这么做：

  • 首先他可以先输入 aaaaaa，之后记录一下从点击登录按钮到错误提示的间隔时间（虽然很短，假设有工具可以记录）
  • 之后再输入 baaaaa，同样记录时间
  • 重复以上过程直到 gaaaaa，会发现从点击登录按钮到错误提示的间隔时间稍微变长了一些
  • 之后小 B 即知道小 A 的密码第一位是 g，之后重复以上步骤即可破解小 A 的密码。

当然这里的例子很蠢，而且也过于理想化，但足够说明问题。反应快的读者可能马上就会知道为什么在观察 ‘gaaaaa’ 的测量结果后小 B 就会知道小 A 首位密码，这是因为执行校验密码是否正确的代码是需要时间的，因此在理想条件下，首位错误和首位正确第二位错误的反馈结果必然是后者时间略长。

这就是一个比较典型的旁路攻击类型，专业的名称叫做计时攻击（timing attack），有兴趣的可以上网搜索了解详情。

预执行（speculation execution）

之后再来了解预执行这个概念，电脑之所以可以执行我们所编写的代码，其背后是由若干硬件协同工作的结果。其中两个比较重要的，一个是内存，一个是CPU。众所周知，CPU执行计算的速度肯定是远大于它读取内存的速度的，这样的结果就是，CPU在对内存读取某些数据的时候，会闲置，这样变造成了浪费。为了提高性能，现代基本大部分硬件制造商都引入了预执行这个机制来压榨CPU的性能。大概的意思如下，比如你写了一段代码：

if(somethingTrueOrFalse) {// TODO ...
}

逻辑上，这个 if 语句内部的代码是否执行，取决于 somethingTrueOrFalse 变量，但是注意，这是逻辑上的，CPU在运行这段代码的时候，可不是这样子的。它可能会直接跳过判定 somethingTrueOrFalse 是真是假的逻辑，直接执行 if 语句内部的代码，之后反过来再根据 somethingTrueOrFalse 的取值情况作出反应，如果为真，则保留执行结果，如果为假，则撤销执行结果。

这里对于预执行的描述是极度简化的，不过足够说明概念了。如果有兴趣可以上网搜索相关文章，尤其是预执行策略方面的，我看了一些，没看完，感觉和AI有的一拼（题外话）。

幽灵和熔断漏洞（Spectre & Meltdown）

这个漏洞是在18年 1 月份被报道出来的，是硬件系统层面的漏洞。关于这个漏洞本身，网上已经有专业的论文对其进行了详尽的介绍，有兴趣可以自行搜索阅读，这里就不展开说了。简单讲，就是结合上文提及的两个概念的两种实际攻击方法。

这里还需要再说一下 CPU 读取数据的方式，CPU 除了利用预执行来提供性能，它本身在从内存读取数据的时候，还会涉及一个缓存的概念。从缓存读取数据的速度是大于内存的，当 CPU 发现将要读取的一个数据在缓存中存在时，它会直接从缓存中读取，这样同样可以提高性能，但是缓存很小同时也很昂贵，所以缓存的大小无法与内存相比。同时，每个程序运行时，CPU 为了防止进程间互相保持独立，它们都拥有属于自己的某块内存区域，假设程序 A 存在一条想要直接越界访问程序 B 内存的指令，这在 CPU 是属于非法的，它不会执行这条指令，而会选择抛出异常并终止程序，然后将其相应的内存数据清零。

之后问题就出现了，假设我们有以下代码：

if (x < arr1.length) {y = arr2[arr1[x]]
}

这个例子在参考链接的文章中你可能会多次见到，这里大概解释一下：

  • arr1 假设是一个比较小的数组，x 是一个我们定义的索引值变量
  • 正常情况下，如果 x 超过 arr1 的长度，程序是要崩溃的，因为它越界了，但是在预执行的前提下，CPU 可能会忽略越界的问题而执行 if 语句内部的代码
  • arr2 是我们提前声明的一个用来储存数据的数组，它储存于内存的另一个区域，它是连续的，而且我们强制它没有拷贝至缓存，只保存于内存（这点在视频中有提及，我这里强调一下）
  • 之后我们假设 arr1 中的位于 x 索引出的值是 k，那么在预执行的前提下，y = arr2[arr1[x]]等价于y = arr2[k]
  • 然后由于我们会把 arr2[k] 这个值付给另一个变量 y，这里其实算是一个访问值的操作，CPU 后将 arr2[k] 位于内存地址的值转入缓存中，而其余元素保留在内存中（因为并未访问）

之后，只需要遍历 arr2 这个数组，当发现某个索引上的值的访问速度远快于其他索引的访问速度时，这个索引既是我们从越界内存中“偷”到的值。至此，一次攻击就完成了，理论上，利用这个漏洞，可以获取缓存区所有地址的值，其中很有可能包含敏感信息，比如密码什么的。

和浏览器的关系

以chrome 举例（用的人多）

Chrome浏览器在处理不同 tab 和不同页面时，会将为它们划分不同的进程，而且受制于同源策略的影响，这些页面之间本应该互不干扰。但是我们知道，同源策略虽然牛逼，但浏览器中仍然存在一些不受制于它约束的 api、标签，比如常见的 img、iframe 和 script等等。诸如以下代码，不知道看文章的诸位有没有写过，反正我是写过，或者说遇见过：

<img src="https://foo/bar/baz/">

有人可能会问，一个 img 标签你 src 属性不填图片的 uri，你是不是傻。其实不是这样的，有时候对网站做一些跟踪和分析时，确实会这么写，因为浏览器会往https://foo/bar/baz/这个地址发送一个 GET 资源的请求，在服务端我们可以利用这个请求做一些追踪的逻辑，同理 script 也可以完成需求。但是这么做的后果就是，虽然 img 帮我们发送了这个请求，但是它却没有得到所期望格式的资源，所以这里实际可以算作一种错误或者异常。而一些攻击者可以利用这一点，比如，在页面嵌入下面的代码：

<img src="https://example.com/secret.json">

来加载跨域私密文件，因为 img 不受同源策略的制约，这个请求是可以发出去的，服务器响应返回后，显然 secret.json 不是一个图片格式的资源，img 不会显示它，但是并不代表负责渲染当前页面的进程的内存中没有保留关于 secret.json 的数据。因此攻击者可以利用上文中提及的漏洞，编写一些代码来“偷”这些数据，从而造成安全隐患。

而 CORB 的作用就是当浏览器尝试以上面代码的方式加载跨域资源时，在资源未被加载之前进行拦截，从而提升攻击者进行幽灵攻击的成本，这里之所以是说提升成本还非彻底解决是因为这个漏洞是基于硬件层面的，所以软件层面只能做有限的修复，有的人可能马上会说，那 CPU 直接去掉或者用户放弃使用预处理功能不就好了吗？理论上是这样的，但是这将导致预处理带来的性能红利瞬间消失，而且 CPU 的架构设计也不是一天两天就能改的，而且就算改了也没办法一下普及。

哪些内容类型受 CORB 保护

当前有三种内容类型受保护，分别是 json、html 和 xml。关于如何针对每种内容类型 CORB 如何对其进行保护，文档中有详细的章节进行介绍，这里就不多说了。我浏览了一遍，大体的规则均是对内容格式进行一些有针对性的校验，以确认它确实是某个内容类型。这个校验结果最终影响 CORB 的运作方式。

CORB 如何运作

这里我引用文档部分章节并做翻译，关于其中的备注可以直接浏览原文档进行查看。

CORB 会根据如下步骤来确定是否对 response 进行保护（如果响应的内容格式是 json、html 或者 xml）:

  • 如果 response 包含 X-Content-Type-Options: nosniff 响应头部，那么如果 Content-Type 是以下几种的话， response 将受 CORB 保护：* html mime type* xml mime type（除了 image/svg+xml）* json mime type* text/plain* 如果 response 的状态是 206，那么如果 Content-Type 是以下几种的话， response 将受 CORB 保护：* html mime type* xml mime type（除了 image/svg+xml）* json mime type* 否则，CORB 将尝试探测 response 的 body：* html mime type，并且探测结果是 html 内容格式，response 受 CORB 保护* xml mime type（除了 image/svg+xml）, 并且探测结果是 xml 内容格式，response 受 CORB 保护* json mime type，并且探测结果是 json 内容格式，response 受 CORB 保护* text/plain，并且探测结果是 json、html 或者 xml 内容格式，response 受 CORB 保护* 任何以 JSON security prefix 开头的 response（除了 text/css）受 CORB 保护这里值得一提的是，对于探测是必须的，以防拦截了那些依赖被错误标记的跨源响应的页面（比如，图片资源但是格式却被标记为 text/html）。如果不进行格式探测，那么会有16倍以上的 response 被拦截。

CORB 如何拦截一个响应

当一个 response 被 CORB 保护时，它的 body 会被覆盖为空，同时 headers 也会被移除（当前 Chrome 仍然会保留 Access-Control-* 相关的 headers）。关于 CORB 的工作方式，一定要和 CORS 做区分，因为它要防止这些被拦截的数据进入渲染当前页面进程的内存中，所以它一定不会被加载并读取。这不同于 CORS，因为后者会做一些过滤操作，数据虽然不可被加载，但是可能仍然保留在渲染进程的内存中。

对于其他 web 平台特性的影响

这里仍然是翻译部分文档中的内容，因为本身写的就很细致了。

CORB 不会影响以下技术场景：

  • XHR and fetch()* CORB 并不会产生显而易见的影响，因为 XHR 和 fetch() 在响应中已经应用了同源策略（比如：CORB 应该仅会拦截那些因缺少 CORS 而发生跨域 XHR 错误的 response）* Prefetch* CORB 会拦截那些到达跨源渲染进程的 response body，但是不会阻止那些被浏览器进程缓存的 response body（然后传递到另一个同源渲染进程）。* Tracking and reporting* 当前存在各种各样的技术，尝试对记录用户访问的服务器发送 web 请求，以检查用户是否已访问某些内容。该请求经常使用隐藏的 img 标签进行发送（我前文提及了），然后服务器以 204 状态码或者 html 文档进行响应。除了 img，还可以使用类似 script、style 和别的可用标签。* CORB 不会对这些技术场景造成影响，因为它们不会依赖于服务器返回响应的内容。这一点同样使用与其他类似的技术场景和 web 特性，只要它们不关心响应即可，比如：beacons，ping，CSP违规报告 等。* Service workers* Service workers 可以拦截跨源 requests 并在其内部人为地构建 response（没有跨源和安全边界），CORB 不会拦截它们。* 当 Service workers 确实缓存了一些跨源的 responses 时，由于这些 responses 对于调用者来讲是透明的，因此 CORB 会拦截它们，但是这并不需要对 Service Worker 作出任何改变。* Blob and File API* 即使没有 CORB 的话，获取跨源的 blob URLs 当前也会被拦截。* Content scripts and plugins* 它们所属的范围并不含在 CORB 的职责内 —— CORB 假设已经有某种合适的安全策略或安全机制存在于这些 content scripts 和 plugins 中（比如 Adobe Flash 已经实现了类似 CORB 的机制，通过 crossdomain.xml）。相关文档：

chromium.googlesource.com/chromium/sr…

www.chromium.org/Home/chromi…

zhuanlan.zhihu.com/p/32784852

www.chromestatus.com/feature/562…

CORP (Cross-Origin Resource Policy)

简单的说 是一个与上面 CORB 配套的 HTTP 请求头，可以全面阻止跨站/跨域资源请求。

作为CORS之外的一个安全补充。也只对非CORS请求有效

并且由于这个策略是通过响应头表示的，因此实际请求不会受到阻止，相反，浏览器通过删除响应体来防止结果泄漏。

注意: 由于 Chrome 中的一个错误，设置跨原产地资源政策可能会破坏 PDF 渲染，使访问者无法阅读某些 PDF 文件的第一页。在生产环境中使用此消息头时要小心。

Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin
  • same-site

只有来自同一站点的请求才能读取资源。

警告: 这不如原点安全。检查两个来源是否相同的网站的算法是在 HTML 标准中定义的，包括检查可以注册的域。

  • same-origin 同源的 只有来自相同的请求`origin`(i.e. scheme + host + port) 可以读取资源* cross-origin 交叉起源 任何的`origin`(同一站点和跨站点)可以读取资源有兴趣的可以看下

github.com/whatwg/fetc…

developer.mozilla.org/zh-CN/docs/…

COEP（Cross-Origin Embedder Policy）

也是一个 HTTP 请求头，规定了该网页中 iframe 嵌入其它网页是否要也遵循 CORP

有兴趣的可以看下

wicg.github.io/cross-origi…

COOP (Cross Origin Opener Policy)

这些功能强大的特性和 document.domain 修改的预防功能在 Chrome 83版本中还没有启用。预计86可以通过flag打开

规定了 window.opener 能不能跨站/跨域访问、domain 能不能被修改

github.com/whatwg/html…

想翻译一下 一直没时间。。web.dev/coop-coep/

关于 opener mathiasbynens.github.io/rel-noopene…## 最后
从时代发展的角度看，网络安全的知识是学不完的，而且以后要学的会更多，同学们要摆正心态，既然选择入门网络安全，就不能仅仅只是入门程度而已，能力越强机会才越多。

因为入门学习阶段知识点比较杂，所以我讲得比较笼统，大家如果有不懂的地方可以找我咨询，我保证知无不言言无不尽，需要相关资料也可以找我要，我的网盘里一大堆资料都在吃灰呢。

干货主要有：

①1000+CTF历届题库（主流和经典的应该都有了）

②CTF技术文档（最全中文版）

③项目源码（四五十个有趣且经典的练手项目及源码）

④ CTF大赛、web安全、渗透测试方面的视频（适合小白学习）

⑤ 网络安全学习路线图（告别不入流的学习）

⑥ CTF/渗透测试工具镜像文件大全

⑦ 2023密码学/隐身术/PWN技术手册大全

如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！

扫码领取

教IT的小王A
关注
  • 51
    点赞
  • 踩
  • 43
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
跨域资源共享 CORS 详解
09-02
所有浏览器都支持该功能IE浏览器不能低于IE10.整个CORS通信过程都是浏览器自动完成不需要用户参与。对于开发者来说CORS通信与同源的AJAX通信没有差别代码完全一样浏览器一旦发现AJAX请求跨源就会自动添加一些附加的...
30 分钟理解 CORB 是什么
weixin_34130389的博客
08-23 441
写在前面 前些日子在调试 bug 的时候，偶然发现这么一个警告： Cross-Origin Read Blocking (CORB) blocked cross-origin response www.chromium.org/ with MIME type text/html. See www.chromestatus.com/feature/562… for more details. 我...
前端提示CORB
JFENG14的博客
12-10 2927
跨域问题，当前端提示CORB时，有可能是后端的nginx设置了只允许同源访问 nginx配置
Cross-Origin Read Blocking (CORB)
学习真香
11-07 2万+
Cross-Origin Read Blocking (CORB) 背景 有一天, 打开浏览器看到控制台报错: Cross-Origin Read Blocking (CORB) 已屏蔽 MIME 类型为 text/html 的跨域响应 https://xx.xxxx.com/stat/record?it=0&lshowp=2560x1440&0.1996155506933639 如需了解详情，请参阅 https://www.chromestatus.com/feature/56297098
jsonp跨域资源引起CORB
weixin_34274029的博客
02-26 2311
一、jsonp的使用 jsonp是实现跨域请求数据的一种方式，解决了由于浏览器同源策略带来的安全限制；虽然浏览器有同源策略的限制，但对于一些特殊的dom元素却可引用非同源资源，例如&lt;img src=""/&gt; &lt;script src=""/&gt;等，下面结合例子说明： jquery直接发起ajax调用 服务端代码 @Re...
什么是跨域？跨域请求资源的方法有哪些？
weixin_34326558的博客
03-10 373
1、什么是跨域？ 由于浏览器同源策略，凡是发送请求url的协议、域名、端口三者之间任意一与当前页面地址不同即为跨域。存在跨域的情况： 网络协议不同，如http协议访问https协议。 端口不同，如80端口访问8080端口。 域名不同，如qianduanblog.com访问baidu.com。 子域名不同，如abc.qianduanblog.com访问def...
你可能不知道的CORS跨域资源共享
10-17
主要给大家介绍了关于CORS跨域资源共享的相关资料，文中通过示例代码介绍的非常详细，对大家的学习或者使用CORS具有一定的参考学习价值，需要的朋友们下面来一起学习学习吧
js跨域资源共享 基础篇
10-22
主要为大家详细介绍了javascript跨域资源共享的相关资料，感兴趣的朋友可以参考一下
旁路攻击（侧信道攻击）
weixin_40191861的博客
07-15 452
在中，又称（英語：）是一種攻擊方式，它基於從密碼系統的物理中獲取的信息而非或是中的理論性弱點（較之例如：時間信息、功率消耗、泄露或甚是聲音可以提供額外的信息來源，這可被利用于对系统的进一步破解。某些側信道攻擊還要求攻擊者有關於密碼系統内部操作的技術性信息，不過，其他諸如差分電力分析的方法在黑盒攻擊中效果明顯。許多卓有成效的側信道攻擊基於由保罗·科切開拓的統計學方法。通过尝试破解的实例。左侧的峰值是在运行RSA迭代中没有乘法的部分时处理器的功率，右侧则是在乘法步骤中处理器的功率。
旁路攻击概述
m0_74043383的博客
02-13 1008
功耗攻击是一种比较常用的旁路攻击方法，它利用硬件电路进行不同操作时 所需功耗不同的特点，通过采集功耗信息来分析硬件电路的工作状态，进而得 到攻击者所需要的信息。为了保证硬件电路的安全性，密码芯片在电路设计阶 段加入抗功耗攻击的措施是非常有必要的。
集成电路安全（三）：旁路攻击基础
叫好与叫座虽然不是对立面，但想在同一个作品中达到双重效果很难。
07-19 285
这种硬件层面的攻击通常以从电子设备获取机密信息为目标。对于密码算法，加密是将普通信息（称为纯文本或明文）转换为难以理解的文本（称为密文）的过程。。与传统的功能测试不同，旁路攻击通常在执行某些操作时要。与密码分析中使用的理论模型（攻击者试图使用数学模型和输入/输出信息组来破坏密码操作）相反，旁路攻击针对的是密码算法的实际硬件系统，即利用特定硬件系统的某些特征对密码设备实施物理攻击，以恢复计算中涉及的秘密参数。
跨域
飞鸿的博客
08-31 5160
  xhr.js?ec6c:178 Cross-Origin Read Blocking (CORB) blocked cross- xhr.js吗?ec6c:178跨源读取阻塞（CORB）阻塞交叉- 前端要用代理 后端cors解决 跨域问题的产生背景 早期为了防止CSRF（跨域请求伪造）的攻击，浏览器引入了同源策略(SOP)来提高安全性。 CSRF（Cross-site req...
解决跨域的两种方案
流年梦里风起舞
11-07 2万+
一、跨域与同源策略 跨域，通俗地讲，是指一个服务A的客户端请求另一个服务B的数据。下面给出了跨域的图示。 在上面这个图中，描述了客户端与服务A关系，也就是说，客户端不允许对服务A以外的服务进行访问。这就是典型的跨域问题。通常同源策略与跨域紧密联系在一起。同源策略，它是由Netscape提出的一个著名的安全策略。现在所有支持JavaScript 的浏览器都会使用这个策略。所谓同源是指，域名，协议，...
跨源读取阻止（CORB）功能阻止了MIME类型为text/html的跨源响应_解决方法
热门推荐
Jude_zhai的博客
06-13 4万+
警告发生在html文件中，原语句为 <script src="http://d3js.org/d3.v3.js"></script> 将src中的http改为https即可消除警告。
web安全（二）——CSRF
远走的兔子博客
08-03 1199
产生原理 CSRF 又称XSRF（Cross-site request forgery / one click attack/session riding），中文跨站请求伪造。CSRF与XSS在攻击手段上有点类似，都是在客户端执行恶意代码, 但CSRF不注重于获取用户Cookie。CSRF不仅可以在源站发起攻击，还可以引导用户访问其他危险网站的同时发起攻击。CSRF攻击是源于WEB的隐式身份验证...
cors跨域资源共享
最新发布
07-28
CORS（Cross-Origin Resource Sharing）是一种机制，用于允许在一个域名下的Web应用程序访问另一个域名下的资源。默认情况下，浏览器会...希望这能解答你关于CORS跨域资源共享的问题！如果还有其他问题，请随时提问。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值