Chrome updates cross-domain rules that will affect web sites

After Chrome V94, a previously unproblematic website interface request now has an error:

Access to Css stylesheet at ‘HTTP :xx’ from origin ‘http://xx’ has been blocked by CORS policy: The request client is not a secure context and the resource is in more-prevate adddress space local

Seeing CORS gives people a sense of cross-domain vision, so the question is, can cross-domain before can not now? Is chrome adding new cross-domain rules? If so, boy, the strange knowledge adds up!

Why update this feature

It is described and implemented according to the private network access specification to prevent web sites from attacking local services.

How do you understand that? Assume that the local Intranet has an HTTP service. Cross-domain access may be enabled for convenience. Such as direct access to the http://127.0.0.1:8080/images can get a lot of personal practical summary hd no learning materials (you goods, you fine taste). Then I went to some malicious online site with code like this:

/ / access to local resources and uploaded to the server to fetch (' http://127.0.0.1:8080/images'). Then ((res) = > {res. ArrayBuffer (). Then (buf = > {/ / Upload data to the server.... // Upload data to the server.... // Upload data to the server.... })});Copy the code

Let’s take a look at which addresses are vulnerable to such attacks:

Address block

Name

Reference

Address space

127.0.0.0/8

IPv4 Loopback

[RFC1122]

local

10.0.0.0/8

Private Use

[RFC1918]

private

Along / 12

Private Use

[RFC1918]

private

192.168.0.0/16

Private Use

[RFC1918]

private

169.254.0.0/16

Link Local

[RFC3927]

private

1/128: :

IPv6 Loopback

[RFC4291]

local

fc00::/7

Unique Local

[RFC4193]

private

fe80::/10

Link-Local Unicast

[RFC4291]

private

::ffff:0:0/96

IPv4-mapped

[RFC4291]

see mapped IPv4 address

These are all non-public IP address blocks, and the above error can be triggered by requesting data from a private service from a public page, or requesting local data from a private service.

As can be seen from the above figure, the following situations are not allowed:

  • Accessing a private service from a public service
  • Accessing a local service from a public service
  • Accessing a local service from a private service

How to solve this problem

  • Access local datahttp://localhost(orhttp://127.*.*.*, http://[::1]), you just need to upgrade the page to HTTPS
  • Access the private IP address, upgrade the target address and access the page are HTTPS
  • Reference a local resource from a public server, such as a CDN
  • In the pilot phase, you can set Chrome ://flags/#block-insecure-private-network-requests to disabled, but this is expected to expire in Chrome V101

Additionally, Chrome does not yet fully implement everything in the specification. For example, in addition to the above solution, it is possible to use CORS pre-request for authorization.

If we use the pre-request method, we just need to set access-Control-allow-private-network :true in the options response header, which is a relatively simple solution.

Afterword.

Some netizens mentioned:

Seems this new protocol doesn’t stop you from downloading examples from this article? HTTPS phishing sites still exist… Just upgrade HTTPS… Is it a little chicken?

This is a good idea. At first, I thought whether there was something wrong with my example or whether it was the norm. After thinking for a while, I felt that there was nothing wrong with the example, and the norm would not have such serious loopholes.

And then I’m going to go back to the relevant information and see if there is a way to deal with it in the specification or is it going to be attacked?

HTTPS is the basis for method cross-site Request forgery (CSRF)

  • HTTPS

    HTTPS by itself does nothing to defend against CSRF. However, HTTPS should be considered a prerequisite for any preventative measures to be trustworthy. However, HTTPS should be considered a prerequisite for any credible preventive measures.

There are same-origin policies to avoid CSRF

  • CORS

    Fortunately, this request will not be executed by modern web browsers thanks to same-origin policy restrictions. This restriction is enabled by default unless the target web site explicitly opens up cross-origin requests from the attacker’s (or everyone’s) origin by using CORS with the following header: Access-Control-Allow-Origin: *

  • Fortunately, modern web browsers do not execute this request (tricking the victim into submitting a malicious request) due to same-origin policy restrictions. This restriction is enabled by default, unless the target site explicitly opens cross-domain requests from an attacker (or everyone) source by using CORS with subscript headers: access-Control-Allow-Origin: *

Private network specification

  • You decide whether to allow access from the pre-request

    with the following implication: private network requests are only allowed if their client is a secure context and a CORS-preflight request to the target origin is successful.

  • Private network requests are allowed only if the client is a security context and the CORS precheck request against the target source succeeds. The security context here can be interpreted as not being intercepted by the browser’s security tools, that is, it is considered secure. The IP address space can also be set in the pre-request to specify what range of addresses can be accessed.

conclusion

So in retrospect, Google Chrome does prohibit direct access to private addresses in the first place (this layer is restricted by private network specifications). However, if the API in the example is already open for all domain names to be requested, then it is naturally vulnerable to cross-site attacks (this layer is restricted by the CORS specification).