Author: evening wind (from the author team of Xin'an Road)

Complimentary book: Linux system security

In front-end development, there are often various cross domain problems. Generally, in addition to iframe, script, link, IMG, SVG and other limited tags, the front-end can support cross domain (which is also related to the use of these tags), other resources are prohibited from cross domain reference. When it comes to cross domain, it is closely related to the browser's homology strategy. Let's first understand why browsers set the same origin policy.

Same origin policy

First of all, the source of the same "source" not only refers to the main domain name of the two pages, but also includes the same protocol, port number and sub domain name of the two domain names. For example, suppose I have a page http://www.a.com/index.html, the domain name is www.a.com, the secondary domain name is WWW, the protocol is HTTP, and the port number is the default 80. The homology of this page is as follows:

http://www.a.com/index.html www.a.com www http 80

The significance of homology policy is to protect the information security of users. In general, websites will store some sensitive information about users in the cookie of the browser. If there is no protection of the same origin policy, then page B can also read the sensitive information stored in the cookie of page a at will, which will cause information leakage. If the user's login status can be read at will by malicious websites, the consequences are unimaginable. It can be seen that the same origin policy is very necessary, which can be said to be the cornerstone of browser security.

In addition to cookie access being restricted by the same origin policy, there are also some operations restricted by the same origin policy:

(1) Unable to read cookies, sessionstorage, localstorage, indexeddb of non homologous web pages

(2) Unable to read and write dom of non homologous web page

(3) Unable to send Ajax request to non origin address (it can be sent, but the browser will reject the response and report an error)

Although all pages are protected by the browser's same origin policy, there are still some ways to bypass the browser's same origin policy restrictions. Let me summarize several known cross domain methods and possible security problems. If there is any other way, please add in the message below.

Five front-end cross domain methods

1, JSONP

Jsonp (JSON with padding) takes advantage of the cross domain feature of < script > tags. The front end and the back end need to agree on a function name. When the current end requests the back end, it returns a segment of JS. This section of JS calls the previously agreed callback function, and passes the data in as parameters to complete the cross domain transmission of data. It may be a little difficult to understand the text in this way. Let's take an example:

<script>

The page to obtain data http://a.com/index.html:

http://a.com/index.html

Visit the page of different domain http://b.com/api? Callback = foo, and the return data is as follows:

http://b.com/api?callback=foo

In this example, the agreed callback function is called foo, and the callback parameter tells the server which function to call to transfer data, that is, what data to transfer. Then the server will return the corresponding data to the page, thus realizing the cross domain data transmission. This is the whole jsonp process. Because this way is to use the characteristics of script tags to achieve cross domain, so only get data.

foo

There are several security issues with this approach:

One is that the API page receiving the request belongs to public use. If it is for internal private use, it will cause a problem of user information disclosure;

Second, if the content of the callback parameter is a section of JS code, XSS problems may occur when the backend is not filtered or the filtering is not strict; third, some vulnerabilities may occur.

2、document.domain

This method has some limitations. It can only be accessed across domains in two pages with the same top-level domain name. Usually, iframe of a different domain is embedded in a page, and two pages cannot access each other, so it is mostly used to control iframe embedded in the page. Then let's talk about the document. Domain in JS. This will display the domain name of the current page. It can also be set, but there are restrictions. It can only be set to the current domain name or top-level domain name. If it is set to a different domain name, an "invalid parameter" error will be reported:

For example, there are now two pages, http://www.a.com and http://a.com, which are different domains. The document.domain of the former domain is www.a.com, and the document.domain of the latter domain is a.com. Introduce the latter page in the previous page, and change the document.domain of the previous page to a.com, then the two pages can operate with each other, that is, realize the cross domain between the same top-level domain name.

http://www.a.com http://a.com www.a.com a.com a.com

3、window.name

For window.name, let's take a look at such a scenario. First, station a:

After setting window.name, it will automatically jump to station B. at this time, we will alert out window.name in the console and find that it is still the data we set in station a. You can see that if you jump to a page in a tag, our window.name will not change. We can use this feature for cross domain. By the way, another page opened from the inside of the page will contain a reference to the previous page, which is also the cause of the target = "blank" vulnerability.

The same technology can also be used in iframe cross domain data transfer.

This is the page with the data:

This is the data page:

Then the browser gives a false report without any emotion

I just cross a domain and give me a big error report. It's OK. We have JS black magic. Make a few changes to the code, change its SRC to the same domain immediately after iframe is loaded, so that you can read the window.name of iframe. In actual development, it can also be set to about: blank instead of the same domain, because this page contains references to the same domain, and because it is a blank page, it can improve the page loading speed.

about:blank

Successfully obtained data across domains:

In security, we usually use window.name to shorten the payload of XSS.

4、postMessage

PostMessage is a new API in HTML5 era. For secure cross domain requests. Literally, we can imagine that one page sends messages to another page to realize cross domain communication. Here is the simplest example:

Station a is the sending data terminal:

Station B is the receiving data terminal:

This is the simplest demo of PostMessage. There is no problem with this cross domain mechanism itself, and the security problem lies in people.

There are two main problems:

One is that station a is the sender of the message. If there is a requirement for the confidentiality of the message, the receiver cannot be written as * and the domain of the received message needs to be specified;

*

Second, as the data receiver, B needs to verify the source of the data before processing the received data to prevent the source from being maliciously forged, so that the page is injected with malicious data. Therefore, the following methods are recommended:

5、browser SOP bug

Although all browsers have the same origin strategy, each browser implements it in different ways. Inevitably, there will be loopholes in the implementation. We can find out the vulnerability of browser homology policy to achieve cross domain access. For example, browser's loose parsing of CSS (cascading style sheets) will lead to cross domain bugs. Here's an example:

https://bugs.chromium.org/p/chromium/issues/detail?id=9877

Three cross domain methods of server

1. Reverse server

Because servers can access data across domains. So we can directly tell the back-end server what data of other domains our front-end wants, let the server help us to read data across domains, get it and then pass it to us, so that the front-end can also process data in other domains. In other words, map resources from other domains to your own domain, so that browsers think they are cognate. This is the principle of the reverse server. Is it very simple. In general, we often use nginx to configure the reverse proxy server.

2, CORS

CORS is very simple to set up. Just return a "allow control allow origin" response header on the relevant page. Similar:

See this article of teacher Ruan Yifeng for details:

http://www.ruanyifeng.com/blog/2016/04/cors.html

CORS cross domain is more like an upgraded version of jsonp, like adding a white list to jsonp. Only requests in the server white list can be responded correctly.

The insecurity of this cross regional approach was also mentioned at the current Defcon conference. In fact, most of the problem is that the acao response header is not configured correctly. If it is set to * directly, it is equivalent to removing the browser's homology policy. All domains can access the files of this domain. A CORS cross domain scanner is provided here to check whether the CORS configuration of the website is secure.

ACAO *

https://github.com/chenjj/CORScanner

3, flash

Little is known about flash cross domain. The technology is also in decline on the web. Here is a brief mention. If station a wants to access station B across domains, it will first check the crossdomain.xml file under station B. if not, the access is unsuccessful. If yes, and it is set to allow site a to access, then site AB can communicate across domains. Here is an example of a crossdomain.xml file:

This is not recommended if you do not want files within the domain to be accessible by any other domain. The right way to do this is to explicitly specify which domains can access the files in this domain.