This article started with a Warn warning from the Chrome console encountered in the landing page project, concerned about affecting page rendering. Here’s a hint,

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://www.example.com/example.html with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details.
Copy the code

Unless otherwise specified, the Browser in this article refers to the Chrome Browser.

preface

This paper will discuss CORB from the following aspects.

  • What is the CORB
  • Why does CORB come into being
  • When does a CORB occur
  • How can we look at corBs when they appear

Browser behavior when CORB occurs

CORB is an algorithm that determines whether to block cross-site resource data from reaching the current site process before it reaches the page, reducing the risk of sensitive data exposure.

– Chrome prompt

When a request CORB occurs, the browser console prints the following warning,

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://www.example.com/example.html with MIME type text/html. See https://www.chromestatus.com/feature/5629709824032768 for more details
Copy the code

Before Chrome 66 or this version, the prompts were slightly different,

Blocked current origin from receiving cross-site document at https://www.example.com/example.html with MIME type text/html
Copy the code

Earlier versions of Chrome still display this warning when the response to a request is inherently wrong or empty, but Chrome 69 and later does not. Experiments 1 and 2 below verify this description.

– Chrome browser behavior

The response body is replaced with an empty body. // The response headers are removedCopy the code

When CORB starts, the requested service is still successful, ‘status: 200’, although the response result is null. For example, if the ‘IMG’ tag is used to report page monitoring data, the request is sent successfully and the server responds normally even though the response result is empty. Experiment 1 below has been verified.

Why CORB?

To put it simply, there are some network security vulnerabilities. In order to prevent them from spreading, Site Isolation emerges. CORB is one of the implementation strategies.

Spectre and Meltdown vulnerabilities

When the malicious code and the normal site exist in the same process, the malicious code can access the memory in the process and carry out a series of access attacks. At this time, the only difficulty for the malicious code to steal data is that it does not know the specific storage location of sensitive data, but it can be detected step by step through CPU pre-execution and SCA. Details can see: zhuanlan.zhihu.com/p/32784852

What is CPU preexecution?

if(condition)
   do_sth();
Copy the code

The CPU executes faster than the memory reads. To increase CPU utilization, the CPU executes the following before the condition is read from memory. The CPU executes the do_sth() statement ahead of time, regardless of whether the if condition returns true. CPU preexecution is determined by the chip maker and built to improve CPU speed and efficiency. The preexecution bonus is not something that can be easily given up, so it is unlikely to change now or in the short term.

In a normal browser, different sites may share the same process

In some cases, regular browsers that do not implement Site Isolution will have code running multiple sites in a process at the same time, allowing malicious sites to take advantage. For example, malicious site a.dd.com embedded A normal browser would run malicious code with the malicious site a.dd.com in the same memory as v.qq.com.

Side-channel Attacks (SCA

In simple terms, it is to use the program running, the system produced some physical characteristics (such as: delay, energy consumption, electromagnetic, error message, frequency, etc.) for speculative attack. It may seem strange, but as early as 1956, Britain had used SCA to gain access to An Egyptian encryption machine in London.

Cache Timing bypass refers to the bypass caused by the difference in memory access time. If you access a variable, and it’s in memory, it takes hundreds of clock cycles to do that, but if you access a variable once, it gets loaded into the Cache, and the next time you access it, it might take a couple of clock cycles to do that, and you can steal specific data based on that access speed. The Spectre and Meltdown vulnerabilities exploit this feature.

How can Spectre and Meltdown vulnerabilities be prevented?

The three key vulnerabilities are CPU preexecution, SCA, and shared processes. Prevention has to start from these three aspects. Looking at SCA, the essence of the variation in algorithm runtime is data processing. Based on the variation in algorithm runtime, the operation and data storage location are inferred, so SCA is very low in prevention. Look at the CPU pre-execution, performance at least 10%, a considerable bonus, chip manufacturers are willing to give up. In this way, only the shared process can be started. Site Isolation is a technology to peel off the shared process, which adopts the way of independent Site and independent process to reduce the threat of vulnerabilities.

Site Isolation

Site isolation ensures that different sites page are placed in different processes, each process run in a sandbox environment, limited in the environment may stop the process to receive other sites back some special types of sensitive information, malicious sites and normal site no longer share the process, that would make malicious sites to steal other sites information more difficult. Starting from Chrome 67, Site Isolation is enabled by default.

It has been verified that the principle of Site Isolation on process independence is that Site instances share a process as long as the first-level domain names are the same, regardless of whether the sub-domain names are the same. If you use iframe to embed a cross-domain site with a different level 1 domain name, a new process is generated to keep the cross-domain site running, unlike the normal browser sharing process described earlier. More detailed content see www.yaoyanhuo.com/blog/site_i…

This is Site Isolation’s process design, so what role does CORB play?

Under the same origin policy, Site Isolation has been well isolated from sites, but there are still things like cross-domain tags, sensitive data will still be exposed, and malicious sites will still enter the memory space. In such a scenario, after logging in to a site some.qq.com, the user visits the bad.dd.com malicious site. The malicious site has the following code,

Timing of CORB occurrence

When the MIME type of the data returned from the cross-domain request does not match the MIME type of the cross-domain tag, the browser will start CORB to protect the data from leakage. The only data types to be protected are HTML XML and JSON. Obviously, cross-domain tags like

MIME type (Multipurpose Internet Mail Extensions)

MIME types are closely related to CORBs, which can be said to be directly dependent on MIME types. Therefore, before reading this article, it’s important to understand what MIME types are.

MIME is an Internet standard that extends the E-mail standard to support more message types. Common MIME types include text/ HTML text/plain image/ PNG application/javascript, which are used to identify the document type of the returned message. Type /subtype. In the HTTP request response header, the content-Type: application/javascript; Charset =UTF-8, MIME Type is part of the content-Type value. The following figure,

MIME Sniffing

Content sniffing is when the response header does not indicate a MIME type or the browser thinks the specified type is wrong, the browser checks the content resource and executes it to guess the correct MIME type of the content. The implementation details of sniffing techniques are different for different browsers in different scenarios and are not covered in this article. Detailed content see: www.keycdn.com/support/wha…

How to disableMIME sniffing?

X-content-type-options: nosniffing adds x-Content-type-options: nosniffing to the response header to tell browsers to trust the MIME Type specified in the content-type and not to use Content sniffing to detect the response Content Type. This method only works with

Official explanation: developer.mozilla.org/en-US/docs/…

How does the browser determine whether the response needs CORB protection?

This is probably the most important aspect of this article, when corBs occur. When satisfying cross-domain tags (e.g.

  • Response header containsX-Content-Type-Options: nosniff
  • The response result status code is206 Partial Content （Developer.mozilla.org/zh-CN/docs/…
  • The result of a browser sniffing the MIME type of the response content is JSON/XML/HTML

This sniffing is used to prevent Content from being blocked by CORB because it is incorrectly marked as a MIME Type, and the sniffing is based on content-type. For example, if the Type is text/ JSON, only json Type checks are performed on the Content. No XML or HTML checks are performed.

HTML MIME type 、 XML MIME type,JSON MIME typeIs understandable. Whytext/plainWill the type also be protected?

Because if the content-type is missing, the MIME Type of the response might be text/plain; HTML, JSON, or XML are sometimes marked as text/palin according to reliable data. Such as,

data.txt

{
  "ret_code": 0."msg": "Request successful!"."data": [1.2.3.4.5]}Copy the code

server.js

app.get('/file'.function getState(req,res,next){
  // res.type('json')
  res.sendfile(`${__dirname}/public/data.txt`)})Copy the code

As shown above, when you start server.js, the Chrome browser returns data. TXT when it accesses /file, even though the response header is Content-Type: text/plain; Charset =UTF-8, the response content is still identified as JSON. Therefore, it is common for text/plain to be used as a JSON tag. If /file is accessed across domains, CORB will appear, as shown in the following figure.

What happens if a script cross-domain request is made for a js resource that is typed with the wrong Content-Type and added with nosiniff?

Many times script files are typed with MIME types such as HTML, XML, and JSON. If Chrome blocks the corresponding content directly, the site in the current domain will not run properly due to the lack of JAVASCRIPT execution content. To avoid this, Chrome determines whether the script response is a protected MIME type (HTML XML JSON) before deciding whether to protect the response. If yes, CORB is enabled. If no, CORB is disabled.

If cross-domain JS resources are set to other types (such as JSON) despite nosniffing, CORB protection must be triggered and JS resource content cannot be returned. If the local domain site needs the JS resource, the node has been connected. A MIME type error plus X-Content-type-options: nosniff triggers CORB, even if the real type of the resource is the same as the cross-domain tag.

For best security policy, developers are advised

  1. Marks the response content correctlyContent-Type;
  2. useX-Content-Type-Options: nosniffbanMIME sniffingThis allows the browser to protect resources or respond more easily and quickly by not sniffing for content MIME types.

When a CORB appears on the console, don’t worry. It generally has no material impact on the page and can be ignored.

Chrome prompts and behavior verification when CORB protection occurs

Although this part belongs to the verification category, it is not enough to simply read a knowledge point. Only after the actual operation and experiment can we get a deeper impression and understanding.

Environment to prepare

Chrome version: Chrome 73.

Node service code index.js,

const express = require('express')
const path = require('path')
const app = express()
const port = process.argv[2] | |3002

app.get('/'.function (req, res) {
  res.send('
hello world! 
')
})

app.get('/data'.function (req, res) {
  console.log('Request ok, only browser has null response data')
  res.json({greeting: 'hello chrome! '})
})

app.listen(port, () => console.log(`app is listening at localhost:${port}`))
Copy the code

Configure the host

127.0.0.1 a.dd.com
127.0.0.1 c.dd.com
127.0.0.1 test.pp.com
Copy the code

Experiment 1: Intest.pp.comThe use ofimgLabel cross-domain requestc.dd.comThe MIME type of the data is JSON

  1. performnpm init 和 npm installInstall service dependency packages
  2. performnode index.jsStart the service
  3. Browser Accesstest.pp.com:3002Open the developer tools
  4. Developer toolsElementsinsert<img src="http://c.dd.com:3002/data"/>(Select the Body element and press F2 to enter HTML editing mode)

  1. View consoleconsoleThat is, visible, CORB prompts.

  1. deleteapp.get('/data')Method to return data{greeting: 'hello chrome! '}, that is, the data returned by the service itself is null, and the CORB prompt disappears, but the request header and response result are still not seen.

Experimental results: 1. CORB does occur when ‘IMG’ is used to request JSON data across domains; 2. When the service itself returns null data, the CORB prompt disappears, but its behavior remains.

Experiment two: Intest.pp.comThe use ofscriptCross-domain requestc.dd.comThe MIME type of the data is JSON

  1. Fill in the deleted code in Experiment 1{greeting: 'hello chrome! '}In your browser, go to test.pp.com and open developer tools.
  2. In developer toolsconsoleBar to insert the JS label and send a cross-domain request.
s = document.createElement('script')
s.src = 'http://c.dd.com:3002/data'
document.head.appendChild(s)
Copy the code

The effect is shown here,

Consistent with img performance, CORB prompt appears. Clears {greeting: ‘Hello Chrome! ‘}, empty the data returned by the service, the effect is the same as img, CROB prompt disappeared. Other behaviors are also the same as IMG.

Experimental result: with ‘IMG’ behavior effect is exactly the same.

Looking at the response to the request in the browser, now looking at the execution of the request in the two experiments,

You can see that despite CORB protection, which makes the response result null and hides the request header, the service request itself always receives and processes the request normally. Therefore, after seeing the CORB, you can generally ignore the prompt.

If an error occurs cross-domain request http://a.dd.com:3002/data itself, is completely without the protection of the CORB, itself has not returned to normal. Therefore, there is even less need for CORB’s cues and actions.

Experiment three: Intest.pp.comRequest across domains inc.dd.comThe server.js file for the service

This experiment aims to verify whether CORB occurs in Chrome when cross-domain REQUEST JS files are set to different MIME types and nosniff.

First, the MIME type of server.js files is the default, and nosniffing is not configured. Add the following code to the c.dd.com service code index.js:

Code snippet 1,

app.get('/file'.function getState(req,res,next){
  res.sendfile(`${__dirname}/public/js/server.js`)})Copy the code

Open developer tools for Chrome test.pp.com and execute the following code in developer tools to request server.js across domains

Code snippet two,

s = document.createElement('script')
s.src = 'http://c.dd.com:3002/file'
document.head.appendChild(s)
Copy the code

The running result is shown below.

As shown in the figure, the true request header is hidden. Response header visible; The response results are visible.

Second, set the MIME Type to JSON, i.e. Content-type: application/json. Charset = UTF-8, nosniff is not set. Index.js /file:

Code snippet three,

app.get('/file'.function getState(req,res,next){
  res.type('json')
  res.sendfile(`${__dirname}/public/js/server.js`)})Copy the code

After executing the second section of this experiment, it is found that the result is exactly the same as the first step (the default MIME type) : The real request header is hidden, and Provisional headers are shown. Response header visible; The response results are visible.

Set the MIME Type to JSON (content-type: application/json). Charset = UTF-8 and add ‘x-Content-type-options ‘:’ nosniffing ‘header. The combination of two response headers means that you are js, but you tell the browser that the MIME type is JSON, and you don’t want the browser to use sniffing to correct the MIME type. Modify the index.js /file part of the code as follows.

Code snippet four,

app.get('/file'.function getState(req,res,next){
  res.type('json')
  res.set({
    'X-Content-Type-Options': 'nosniff'
  })
  res.sendfile(`${__dirname}/public/js/server.js`)})Copy the code

The experiment code snippet ii is executed again, and the running results are shown as follows.

As shown in the figure, during cross-domain request to JS files, if nosniff is not set, no matter what MIME type is set, only the request header is not displayed, and the response header and result are normally displayed. If nosniff is set and the MIME type is not JS, CORB protection is triggered, and cross-domain JS cannot be loaded properly.

Therefore, if a cross-domain site c.dd.com cooperates with a local site test.pp.com, and nosniff headers are added to reduce MIME type sniffing time, ensure that the MIME types set are consistent with JS files! Otherwise the domain site can not get cross-domain site JS resource data!

— — — — — — — — — — — — — — — — — about the CORB, Chrome performance and behavior validation end — — — — — — — — — — — — — — — — — — —

The original address: www.yaoyanhuo.com/blog/corb

Refer to the content

  • Official CORB behavior description: www.chromium.org/Home/chromi…
  • CORB Explainer:chromium.googlesource.com/chromium/sr…
  • Speculative side – channel attack techniques: security.googleblog.com/2018/01/tod…
  • New Chrome browser security function Site: www.trustauth.cn/wiki/26052….
  • What is 30 minutes understand CORB: www.cnblogs.com/oneasdf/p/9…
  • X-Content-Type-Options:developer.mozilla.org/zh-CN/docs/…
  • Browser sniffing the MIME type: www.keycdn.com/support/wha…
  • Read on, there was a content sniffing bug in IE: www.safebase.cn/article-131…
  • How the browser works: www.infoq.cn/article/CS9…
  • Explain to the programmer Spectre and Meltdown: zhuanlan.zhihu.com/p/32784852
  • Bypass attack: zh.wikipedia.org/wiki/ bypass attack
  • V8 engines: zhuanlan.zhihu.com/p/27628685
  • Some CORB behaviors under discussion: github.com/whatwg/fetc…
  • The fetch API:developers.google.com/web/updates…

The author’s blog: www.yaoyanhuo.com