Cross-origin cross-origin request

Cookie

• 1993 ushered in the img tag, which was the first time web ushered in resource loading

  <img src="foo.jpg" />
  <img src="http://somewhere.com/foo.jpg" />

• 1994

  Set-Cookie: foo=bar

• 1995

  <img src="http://somewhere.com/foo.jpg" />
  <script src="http://somewhere.com/foo.js" ></script>
  <iframe src="http://somewhere.com/foo.html" />

  At first this design will cause serious problems: no matter the website, as long as the above tag is included, it will carry cookies to visit.

Not to mention such a request.

<form action="http://somewhere.com./submit"></form>

So http restricts access through the header Origin

• 1999

  // XMLHttpRequest 的前身
  new ActiveXObject('Microsoft.XMLHTTP');

• 2008

  var req = new XMLHttpRequest()
  req.addEventListener('load', loadListener);
  req.open('GET', 'https://example.com/data.txt');
  req.send();

now

const res = await fetch('http://example.com/data.txt', {
    credentials: 'include',
});

Now we have used this method to request, but it is also limited by whether the server responds (below is why some servers respond) .

Cross-Origin Resource Sharing (CORS)

We use access-control-allow-origin to determine which resources can be accessed across domains, such as setting access-control-allow-origin: * to allow all resources to be accessed. And decide whether to carry cookie credential

access-control-allow-credentials: true decides whether to allow you access to cookie . But at the same time, you must specify the URL for cross-domain access through access-control-allow-origin .

These headers are already set in the request we make through the browser, and we don't need to care. For example, when we send the request through <form> , Content-Type has been set to, for example, x-www-form-urlencoded .

A quick tip: you can send a POST request set to Content-type: text/plain . For example, send email through <form> , as long as the blank line interval like x-www-form-urlencoded is guaranteed.

Referrer

When jumping from one website to another, there will be this header information

Origin

Referrer is not reliable, so there is the header information of Origin . Origin will appear in cross-origin requests.

Generally speaking, it is safe enough that we restrict the access-control-allow-origin website.

Except for the CORS request with GET , other GET requests do not carry Origin . You can know whether this is a cross-domain request by judging Origin .

Dangerous cookies across domains

When we make a request without cookie it can cause a lot of problems. First of all, we need to know when access-control-allow-origin: * is safe, such as IoT devices distributed at home, local requests. Other than that, it may trigger CSRF attack.

restrict cookies

Such as tracking through pictures. When you visit other.com , <img /> will allow setting cookie for tracking.

<!-- site: other.com -->
<img src="http://statics.com/user-avatar-a.png" />

Set SameSite: Strict | Lax | None . Lax does not allow img , iframe , AJAX , POST forms to carry cookie (current site is: other.com) . However, Lax allows <a> link, preload request, and GET form to carry cookie in three cases.

Set-cookie: sessionid=1234567; SameSite=Lax; HttpOnly; Max-Age=3153600

SameSite: Strict This will cause all cross-domains without cookie . For example, jumping to github on a website other than github will not carry cookie . At this time, github will show that you are not logged in.

httponly : javasript cannot be obtained cookie

Cross-Origin Resource Policy (CORP)

Cross-Origin-Resource-Policy: same-site tagged same-site can only be loaded from the same site.

Cross-Origin-Resource-Policy response header instructs the browser to block passive cross-origin/cross-site requests to the specified resource.

Add the header information of CORP to the following request, and the image will fail to load.

<!-- site: other.com -->
<img src="http://statics.com/user-avatar-a.png" />

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

CORB

The following scenario cannot be handled by the same cookie , although you can put cookie in the html request.

<img src="http://example.com/secret.html" />

This request will still put the request for the html file into the process to indicate that the current request is processed. This may cause some problems. Meltdown and Spectre

Cross-Origin-Read-Blocking blocks cross-origin request actions, and cross-origin returns are also blocked. For example, the above request will not enter the browser's processing process.

Before the request enters the process, it will pay attention to mine type if it is nosniff ( nosniff will prevent some browser optimizations for content-type ). Chrome Browser requests for html files and not cross-domain will block.

CORB is not header information

Cross-Origin Embedding Policy (COEP)

Cross-Origin-Embedder-Policy: require-corp document can only load resources from the same origin, or resources that are explicitly marked as loadable from another origin.

In order to load resources from other sources, cross-origin resource sharing (CORS) or cross-origin resource policy (CORP) need to be supported.

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Resource-Policy: cross-origin