Recent browser upgrades have encountered several issues due to new versions that cross domains. So let’s review that.

What is cross-domain

Generalized cross-domain

<link>, <script>, <img>, <frame> and other DOM tags, as well as background: URL (), @font-face() and other file external links. Js-initiated Ajax requests, DOM and JS object cross-domain operations, etcCopy the code

It’s called cross-domain

A class of request scenarios restricted by the same origin policy of the browser.

The Same Origin Policy (SOP) is a convention introduced by Netscape into the browser in 1995. It is the core and most basic security function of the browser. Without the Same Origin policy, the browser is vulnerable to XSS and CSFR attacks. Same-origin means that the protocol, domain name, and port are the same. Even if two different domain names point to the same IP address, they are not same-origin.

The same origin policy restricts the following behaviors:

1.) Cookie, LocalStorage, and IndexDB cannot be read. 2.) DOM and Js objects cannot be obtainedCopy the code

Common cross-domain scenarios

URL that whether to allow communication http://www.domain.com/a.js http://www.domain.com/b.js the same domain name, Different file or path to allow http://www.domain.com/lab/c.js http://www.domain.com:8000/a.js http://www.domain.com/b.js the same domain name, Different ports Do not allow the http://www.domain.com/a.js https://www.domain.com/b.js the same domain name, Different protocols Do not allow the http://www.domain.com/a.js http://192.168.4.12/b.js domain names and domain name corresponding to the same IP is not allowed to http://www.domain.com/a.js http://x.domain.com/b.js Same primary domain, Different subdomains Do not allow the different domain name http://domain.com/c.js http://www.domain1.com/a.js http://www.domain2.com/b.js Don't allowCopy the code

Cross-domain solutions

1. Cross domains through JSONP

Document.domain + iframe cross domain

3. Location. hash + iframe

4, window.name + iframe cross domain

5. PostMessage crosses domains

6. Cross-domain Resource Sharing (CORS)

7, Nginx proxy cross domain

Nodejs middleware proxy across domains

9. WebSocket protocol is cross-domain

These are some of the methods that were used before the browser version explosion. I can’t keep up with all this. Chrome 83 developer tools supports DEBUGGING for COEP and COOP, while Firefox 74 supports CORP, plus previously familiar CORS and unfamiliar CORB. The CO* family prospered.

Familiar and strange CO* family

Cross-origin Resource Sharing (CORS)

Let’s start with what the family knows best

CORS is a W3C standard, which stands for “Cross-origin Resource Sharing”.

CORS requires both browser and server support. Currently, all browsers support this function, and Internet Explorer cannot be lower than Internet Explorer 10.

Browsers classify CORS requests into two categories: Simple request and not-so-simple Request.

A simple request

Simple requests are compatible with forms because historically forms have been able to make cross-domain requests. The cross-domain design of AJAX is that as long as the form can be posted, AJAX can be posted directly.

(1) Request method is one of the following three methods:

  • HEAD
  • GET
  • POST

(2) HTTP headers do not exceed the following fields:

  • Accept

  • Accept-Language

  • Content-Language

  • Last-Event-ID

  • Content-type: Application/X-www-form-urlencoded, multipart/form-data, text/plain

For simple requests, the browser directly issues CORS requests. Specifically, add an Origin field to the header information. Indicates the source (protocol + domain name + port) from which the request comes. Based on this value, the server decides whether to approve the request or not.

If Origin does not specify a licensed source, the server will return a normal HTTP response. The browser realizes that the response header does not contain the Access-Control-Allow-Origin field (more on that below), and it throws an error that is caught by XMLHttpRequest’s onError callback. Note that this error cannot be identified by the status code, because the status code for the HTTP response might be 200.

If Origin specifies a domain name within the license, the server returns a response with several additional header fields.

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
Copy the code

In the header above, there are three fields related to CORS requests, all beginning with Access-Control-.

(1) Access – Control – Allow – Origin

This field is required. Its value is either the value of the Ori ‘gin field at the time of the request, or an *, indicating acceptance of requests for any domain name.

(2) Access – Control – Allow – Credentials

This field is optional. Its value is a Boolean value indicating whether cookies are allowed to be sent. By default, cookies are not included in CORS requests. If set to true, the server explicitly approves that cookies can be included in the request and sent to the server. This value can only be set to true if the server does not want the browser to send cookies.

(3) the Access – Control – Expose – Headers

This field is optional. In CORS requests, the getResponseHeader() method of the XMLHttpRequest object takes only six basic fields: Cache-control, Content-language, Content-Type, Expires, Last-Modified, Pragma. If you want to get other fields, you must specify access-Control-expose-headers. The above example specifies that getResponseHeader(‘FooBar’) can return the value of the FooBar field.

Non-simple request

Preview the request

Non-simple requests are requests that have special requirements on the server, such as the request method being PUT or DELETE, or the content-Type field being of Type Application/JSON.

CORS requests that are not simple requests are preceded by an HTTP query request, called a “preflight” request.

The browser asks the server if the domain name of the current web page is on the server’s license list, and what HTTP verb and header fields can be used. The browser issues a formal XMLHttpRequest request only if it receives a positive response; otherwise, an error is reported.

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

In the code above, the HTTP request is PUT and sends a Custom Header x-custom-header.

The browser realizes that this is not a simple request and automatically issues a “pre-check” request, asking the server to confirm that it is ok to do so. Here is the HTTP header for this “precheck” request.

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...
Copy the code

The request method for the “precheck” request is OPTIONS, indicating that the request is being queried. In the header information, the key field is Origin, indicating which source the request came from.

In addition to the Origin field, the precheck request header contains two special fields.

(1) Access – Control – Request – Method

This field is required to list which HTTP methods are used by the browser for CORS requests, in this example PUT.

(2) Access – Control – Request – Headers

This field is a comma-separated string that specifies the additional Header field to be sent by a browser CORS request, x-custom-header in the example above.

Response to precheck request

After receiving the precheck Request, the server checks the Origin, access-Control-request-method, and access-Control-request-headers fields and confirms that cross-source requests are allowed, it can respond.

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
Copy the code

In the HTTP response above, the key is the Access-Control-Allow-Origin field, which indicates that [http://api.alipay.com](http://api.alipay.com) can request data. This field can also be set to an asterisk to indicate approval of any cross-source request.

Access-Control-Allow-Origin: *
Copy the code

If the server denies the precheck request, it will return a normal HTTP response, but without any CORS related header fields. At this point, the browser decides that the server did not approve the precheck request, and therefore fires an error that is caught by the ONError callback function of the XMLHttpRequest object. The console will print the following error message.

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

Other CORS related fields that the server responds to are as follows.

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

(1) Access – Control – Allow – the Methods

This field is required, and its value is a comma-separated string indicating all methods supported by the server for cross-domain requests. Notice that all supported methods are returned, not just the one requested by the browser. This is to avoid multiple “pre-check” requests.

(2) Access – Control – Allow – Headers

The access-Control-allow-HEADERS field is required if the browser Request includes the access-Control-request-HEADERS field. It is also a comma-separated string indicating all header information fields supported by the server, not limited to those requested by the browser in precheck.

(3) the Access – Control – Allow – Credenti * * * * als

This field has the same meaning as a simple request.

(4) the Access – Control – Max – Age

This field is optional and specifies the validity period of the precheck request, in seconds. In the result above, the validity period is 20 days (1728000 seconds), which allows the response to be cached for 1728000 seconds (20 days), during which time another precheck request is not issued.

Normal browser requests and responses

Once the server passes the “precheck” request, every subsequent normal BROWSER CORS request will have the same Origin header field as a simple request. The server also responds with an Access-Control-Allow-Origin header field.

The following is a normal CORS request for the browser after the “precheck” request.

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...
Copy the code

The Origin field in the header above is automatically added by the browser.

The following is a normal response from the server.

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

In the header above, the access-Control-Allow-Origin field is mandatory for each response.

withCredentials

As mentioned above, CORS requests do not send cookies and HTTP authentication information by default. To send cookies to the server, specify the access-Control-allow-credentials field with the server’s permission.

Access-Control-Allow-Credentials: true
Copy the code

On the other hand, the developer must turn on the withCredentials attribute in the AJAX request.

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;
Copy the code

Otherwise, the browser won’t send a Cookie, even if the server agrees to do so. Or, if the server asks for a Cookie, the browser won’t handle it.

However, if the withCredentials setting is omitted, some browsers still send cookies together. In this case, you can explicitly disable the withCredentials.

xhr.withCredentials = false;
Copy the code

Note that access-Control-allow-Origin cannot be set to an asterisk if cookies are to be sent, and must specify an explicit domain name consistent with the requested web page. At the same time, cookies still follow the same origin policy, only the Cookie set with the server domain name will be uploaded, cookies of other domain names will not be uploaded, and (cross-source) document. Cookie in the original web page code can not read cookies under the server domain name.

CORB (cross-origin Read Blocking)

I don’t know if you saw this warning on the console when you were debugging a 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.

I remember that warning for a long time. I never did. I looked it up this time, too

Take a look at the document given first

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

An algorithm that identifies and blocks cross-domain resources loaded by the browser before they are loaded onto the page.

Front knowledge

Before we get down to business, let’s take a look at some positions that we don’t usually touch.

www.bilibili.com/video/av181…

Side-channel Attacks

The first thing you need to know is the term bypass attack. For an explanation of the term itself, you can search Wikipedia. To put it simply, it is a means to attack by obtaining information from the physical implementation layer of the software system. During the normal operation of the software system, some edge features are generated, which can reflect some privacy information.

This may seem A little abstract, but let’s take the example listed in the video link below to illustrate. Suppose that the account password of Little A is Gyease, and little B wants to crack the password of little A, he can do as follows:

  • First he can typeaaaaaa“, and then record the time between hitting the login button and the error message (albeit very short, assuming there is a tool to record it).
  • And then type inbaaaaa, also record the time
  • Repeat the process untilgaaaaaYou’ll notice that the time between hitting the login button and the error message is slightly longer
  • And then little B knows little A’s password and the first digit isg, then repeat the above steps to crack the password of little A.

The example here is silly, of course, and idealistic, but it’s illustrative enough. Quick readers may will soon know why after observation ‘gaaaaa’ measurements of small B will know A password first, because the time is needed to check the password is correct code execution, so in ideal conditions, the first error and the first the second error in the feedback of the result is right the latter time slightly longer.

This is a typical type of bypass attack, known professionally as timing attack. If you are interested, you can search the Internet for details.

Initial execution

Then, to understand the concept of pre-execution, the computer can execute the code we write because several pieces of hardware work together. Two of them are important, one is memory and the other is CPU. As we all know, the CPU must be able to perform calculations much faster than it can read memory. As a result, the CPU will be idle while reading some data from memory, resulting in waste. In order to improve performance, most modern hardware manufacturers have introduced the mechanism of pre-execution to squeeze CPU performance. If you write a piece of code:

if(somethingTrueOrFalse) {
  // TODO ...
}
Copy the code

Logically, whether or not the code inside the If statement executes depends on the somethingTrueOrFalse variable, but note that this is logically something the CPU does not do when running this code. It might simply skip the logic that determines whether a somethingTrueOrFalse is true, execute the code inside the if statement, and then in turn react to somethingTrueOrFalse by preserving the execution if it is true, or keeping the execution if it is false, The result is cancelled.

The description of pre-execution here is extremely simplistic, but sufficient to illustrate the concept. If you are interested, you can search online for related articles, especially on pre-execution strategy. I read some of them, but I didn’t finish them.

Spectre & Meltdown

The bug, which was reported in January 2018, is at the hardware system level. About this vulnerability itself, there has been a professional paper on the Internet on its detailed introduction, interested in their own search to read, here will not expand to say. In short, they are two practical attack methods that combine the two concepts mentioned above.

A word about how the CPU reads data. In addition to providing performance through pre-execution, the CPU itself involves the concept of a cache when it reads data from memory. The speed of reading data from cache is faster than that from memory. When the CPU discovers that a data to be read is in the cache, it will read it directly from the cache. This also improves performance, but the cache is small and expensive, so the size of the cache is not comparable to that of memory. At the same time, each program runs, the CPU to prevent process between independent each other, they all have their own A piece of memory area, assume that the program is A want A cross-border access program memory B instructions directly, which is illegal in CPU, it will not perform this instruction, and choose an exception is thrown and termination procedures, The corresponding memory data is then cleared to zero.

Then the problem arises. Suppose we have the following code:

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

This is an example you may see many times in the referenced articles, but here’s a rough explanation:

  • Arr1 is assumed to be a small array, and x is an indexed variable that we define
  • Normally, if x exceeds the length of arr1, the program will crash because it is out of bounds, but under preexecution, the CPU may ignore the out-of-bounds problem and execute the code inside the if statement
  • Arr2 is an array that we declared ahead of time to store data in, it’s stored in another area of memory, it’s continuous, and we’re enforcing that it’s not copied to cache, it’s just stored in memory (this is mentioned in the video, I’ll emphasize it here)
  • Then we assume that the value in arr1 indexed by x is k, and with pre-execution,y = arr2[arr1[x]]Is equivalent toy = arr2[k]
  • And since we’re going to pay arr2[k] to another variable, y, this is actually a value access operation. The CPU then transfers the arr2[k] value to the cache, leaving the rest of the elements in memory (because it’s not accessed).

After that, we simply iterate through the array ARR2, and when we find that the value on one index is accessed much faster than the value on the other, that index is both the value we “stole” from out-of-bounds memory. At this point, an attack is complete. In theory, this vulnerability can be exploited to obtain the values of all the addresses in the cache, which may contain sensitive information, such as passwords.

Relationship to the browser

Take Chrome as an example.

Chrome divides tabs and pages into separate processes and is subject to the same origin policy, which means that the pages should not interfere with each other. However, we know that the same origin policy is great, but there are still some apis and tags in browsers that are not subject to it, such as the common img, iframe and script. I don’t know if any of you have written this, but I have, or have come across it:

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

One might ask if an img tag does not include a uri for your SRC attribute. The browser sends a request to https://foo/bar/baz/ for a GET resource. On the server side, we can use this request to do some tracing logic, and script can also do the same. The consequence of this, however, is that although IMG sent the request for us, it didn’t get the resource in the expected format, so this actually counts as an error or exception. Some attackers can take advantage of this by, for example, embedding the following code in a page:

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

Since IMG is not subject to the same origin policy, this request can be sent. When the server responds, it is clear that secret.json is not an image resource and IMG will not display it. But that doesn’t mean the process responsible for rendering the current page doesn’t have data about secret.json in memory. Therefore, attackers can exploit the vulnerabilities mentioned above and write code to “steal” this data, thereby causing security risks.

And the role of the CORB is when the browser attempts to load cross-domain resources in the form of code above, before loading resources have not been to intercept, so as to improve the attacker ghost attack cost, here mean increase cost is not yet completely solve because the hole is based on the hardware level, so the software can only be limited to repair, Some people might immediately say, well, wouldn’t it be better to just get rid of the CPU or give up using preprocessing? That’s true in theory, but the performance benefits of preprocessing disappear in a flash, and CPU architectures can’t be changed overnight, and even if they were, they wouldn’t be popular.

Which content types are protected by CORB

There are currently three content types protected: JSON, HTML, and XML. There are detailed sections in the documentation on how each content type is protected by CORB, which are not covered here. I looked around, and the general rule is to do some targeted validation of the content format to make sure it is indeed a content type. This verification result ultimately affects the way CORB operates.

How does CORB work

Here I quote some chapters of the document and translate them. You can browse the original document for comments.

CORB determines whether to protect the response (if the content of the response is in JSON, HTML, or XML) by following the following steps:

  • If the response contains x-Content-type-options: nosniffing header, then the response is protected by CORB if the content-type is any of the following:

  • html mime type

  • XML MIME Type (except image/ SVG + XML)

  • json mime type

  • text/plain

  • If the state of response is 206, then response is protected by CORB if the content-Type is one of the following:

  • html mime type

  • XML MIME Type (except image/ SVG + XML)

  • json mime type

  • Otherwise, CORB will try to probe the body of response:

  • HTML MIME type, and the probe result is HTML content format, response is protected by CORB

  • XML MIME type (except image/ SVG + XML), and probe result is XML content format, response is protected by CORB

  • Json MIME type, and the probe result is a JSON content format. Response is protected by CORB

  • Text /plain, and the probe results are in JSON, HTML, or XML content format, and Response is protected by CORB

  • Any response (except text/ CSS) that begins with JSON security prefix is protected by CORB

It is worth mentioning here that this is necessary for probes to prevent interception of pages that rely on cross-source responses that have been incorrectly marked (for example, image resources but are marked as text/ HTML). If format detection is not performed, more than 16 times of response will be intercepted.

How does CORB intercept a response

When a response is protected by CORB, its body is overwritten as empty and headers are removed (currently Chrome still keeps the access-Control -* associated headers). It is important to distinguish CORB from CORS in that it prevents the intercepted data from entering the memory of the process rendering the current page, so it must not be loaded and read. This is different from CORS, which does some filtering and the data may not be loaded but may still remain in the memory of the renderer process.

Impact on other Web platform features

Here is still the content of the translation part of the document, because it is written very carefully.

CORB does not affect the following technical scenarios:

  • XHR and fetch()

  • CORB doesn’t make a noticeable difference because XHR and FETCH () already apply the same origin policy to their responses (e.g., CORB should only intercept responses that have cross-domain XHR errors due to a lack of CORS)

  • Prefetch

  • CORB intercepts response bodies that reach the cross-source renderer, but does not block response bodies that are cached by the browser process (and then passed to another homologous renderer).

  • Tracking and reporting

  • A variety of techniques exist to try to check if the user has accessed something by sending a Web request to the server that logs the user’s access. The request is often sent using a hidden IMG tag (as I mentioned earlier), and the server responds with a 204 status code or AN HTML document. In addition to img, you can use tags like Script, style, and other available tags.

  • CORB does not affect these technical scenarios because they do not depend on what the server returns in response. This also uses similar technical scenarios and Web features as well, as long as they don’t care about responses, such as beacons, ping, CSP violation reporting, etc.

  • Service workers

  • Service Workers can intercept cross-source requests and artificially build responses within themselves (without cross-source and security boundaries) that CORB does not intercept.

  • When Service workers do cache some cross-source responses, CORB intercepts them because they are transparent to the caller, but this does not require any changes to the Service Worker.

  • Blob and File API

  • Obtaining cross-source BLOb URLs is currently blocked even without CORB.

  • Content scripts and plugins

  • Their scope is not within CORB’s responsibility — CORB assumes that there is already some kind of security policy or mechanism in place in these Content scripts and plugins (for example, Adobe Flash already implements a corb-like mechanism, Through crossdomain.xml).

Related documents:

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)

Simply put, it is an HTTP request header that matches the CORB above and can completely block cross-site/cross-domain resource requests.

As a security supplement to CORS. Also only valid for non-CORS requests

And because this policy is represented by the response header, the actual request is not blocked; instead, the browser prevents the result from leaking by removing the response body.

Note: Due to an error in Chrome, setting the cross-origin resource policy may break PDF rendering and prevent visitors from reading the first page of some PDF files. Be careful when using this header in a production environment.

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

Only requests from the same site can read resources.

Warning: This is not as secure as origin. The algorithm for checking whether two sites from the same source are the same is defined in the HTML standard, including checking which domains can be registered.

  • Same-origin is only the same request

    origin

    `

    (I.E. Scheme + Host + port) can read resources

  • Cross-origin any ‘

    origin

    Resources can be read (both at the same site and across sites)

If you’re interested, take a look

Github.com/whatwg/fetc…

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

COEP (Cross-origin Embedder Policy)

Also an HTTP request header that specifies whether the iframe embedded in the web page should also comply with CORP

If you’re interested, take a look

Wicg. Making. IO/cross – origi…

COOP (Cross Origin Opener Policy)

These powerful features and protection against document.domain modifications are not yet enabled in Chrome 83. It is expected that 86 can be opened through flag

It specifies whether window.opener can be accessed cross-site/cross-domain and whether the domain can be modified

Github.com/whatwg/html…

I have no time to translate. web.dev/coop-coep/

About the opener mathiasbynens. Making. IO/rel – noopene…