Security Analysis of cross-origin Resource Sharing (CORS)

I. background

We are familiar with the same-source browser policy. Client scripts in different domains cannot read and write resources of the other party. However, there are some scenarios in practice that require cross-origin read/write, so there are some hack methods for cross-origin. For example, do a proxy in the same domain, JSON-P, etc. However, these methods are flawed and cannot implement cross-origin read/write perfectly. Therefore, in the XMLHttpRequest v2 standard, a CORS (Cross Origin Resourse-Sharing) model is proposed to provide secure and convenient Cross-Origin read/write resources. Currently, mainstream browsers support CORS.

Ii. Technical Principles

CORS defines two types of cross-origin requests: simple cross-origin requests and non-simple cross-origin requests. When a simple cross-origin request is sent, the request method is HEAD, GET, and POST. The request header contains only four fields: Accept, Accept-Language, and Content-Language, last-Event-ID; If Content-Type is set, the value can only be application/x-www-form-urlencoded, multipart/form-data, text/plain. It is awkward to say. Simply put, a whitelist is set. Only simple requests meet this condition. Other non-conforming requests are non-simple requests.

The reason for this classification is that the browser processes simple requests and non-simple requests differently. When we need to send a cross-origin request, the browser will first check this request. If it meets the simple cross-origin request described above, the browser will immediately send this request. If the browser finds that this is a non-simple request, For example, the request header contains the X-Forwarded-For field. At this time, the browser will not immediately send this request, but there is a preflight, with the server verification process. The browser first sends a pre-check request for the options method. Is an example. If the pre-check succeeds, this request is sent; otherwise, this cross-origin request is not rejected.

The following describes in detail how to control secure cross-origin requests. Let's take a look at the pre-check process for non-simple requests. The browser sends an options Method Request first. With the following fields:

Origin: a common HTTP request also carries the Origin information. In CORS, the Origin information is used for backend comparison, indicating the source domain.

Access-Control-Request-Method: Method of the next Request, such as PUT and DELETE

Access-Control-Request-Headers: Custom Headers. All Headers set using the setRequestHeader method are included in the header by commas.

If cors is configured on the server, the corresponding fields are returned. The specific fields are explained in the returned results.

Access-Control-Allow-Origin:

Access-Control-Allow-Methods:

Access-Control-Allow-Headers:

Then, the browser determines whether to send non-simple requests based on the return value of the server. A simple request is directly sent, but an origin field is added to indicate the origin of the Cross-origin request. After the server processes the request, the following control fields are added to the returned results:

Access-Control-Allow-Origin: the domain that allows cross-Origin Access. It can be a list of domains or a wildcard "*". Note that the Origin rule is valid only for the domain name and not for the subdirectory. The http://foo.example/subdir/ is invalid. However, different subdomains need to be set separately. The rules here can refer to the same-origin policy.

Access-Control-Allow-Credentials: whether to Allow requests to carry verification information, which will be explained in detail below

Access-Control-Expose-Headers: The Return header that allows the script to Access. After the request is successful, the script can Access the header information in XMLHttpRequest (it seems that webkit does not implement this)

Access-Control-Max-Age: the number of seconds that the request is cached. In this time range, all requests of the same type will not send pre-check requests, but directly use the returned header as the judgment basis, which is very useful and greatly optimizes the number of requests.

Access-Control-Allow-Methods: allowed request Methods, separated by commas

Access-Control-Allow-Headers: allows custom Headers separated by commas (,), which are case insensitive.

Then, the browser determines whether to open the result to the client script to read or block it by returning these control fields of the result. If cors is not configured on the server and no control field is set for the returned result, the browser will block the script from reading the returned information.

Iii. Security Risks

Pay attention to this process. When the server receives a cross-origin request, it does not verify the request first, but processes the request first. So to some extent. Cross-origin write resources are implemented in browsers that support cors, breaking the traditional same-origin policy and cannot read or write resources across domains.

If the program is lazy, it sets Access-Control-Allow-Origin to Allow cross-Origin requests from all domains. The cors security mechanism is almost ineffective. But don't be happy too early. In fact, there is a good limit in the design. The request sent by xmlhttprequest uses "withCredentials" to carry the cookie. If a target domain is set to allow cross-domain requests from any domain, the request carries the cookie, which is illegal. (That is, if you need to implement cross-origin requests with cookies, you need to explicitly configure the allowed source domain. The configuration of any domain is illegal.) the browser will block the returned results. Javascript cannot obtain the returned data. This is the last line of defense of the cors model. Without this restriction, javascript can obtain the csrf tokens in the returned data and various sensitive data. This restriction greatly reduces the risk of cors.

Iv. Attack Model

There are two types of attacks. One is to embed a cross-origin request on a webpage controlled by an attacker. The user accesses the link and executes a cross-origin request to attack the target, such as accessing sensitive intranet resources. In addition, a normal webpage is embedded with cross-origin requests on the page controlled by attackers to hijack users' sessions.

V. attack scenarios

First look at the attack scenario of the first approach:

1. Complicated csrf. Traditional csrf uses html tags and forms to send requests. There is no way to implement csrf in some complex steps, such as simulating shopping, adding shopping cart first, settlement, filling in information, and so on. For example, upload a file. For more information, see use csrf to upload files.

2. Access Intranet sensitive resources. This can be achieved under certain conditions. For example, if the Intranet server is configured

Access-Control-Allow-Origin: * allows any cross-Origin requests from any domain.

When a user accesses a malicious webpage, the user executes a request to the Intranet server 192.168.1.123/password.txt. After receiving the response from the server, the script sends the content to the attacker's server.

Scenario 2:

1. Interactive xss. Refer to the shell of the future tool mentioned in the attack method of unveiling HTML5. Attackers can use cors to hijack user sessions by bypassing anti-session hijacking methods, such as HTTP-Only cookies and session IDs bound to IP addresses.

2. When a program writes an ajax request, it does not have strict restrictions on the target domain. It is similar to url redirection. Facebook has seen such a case. Javascript uses parameters in the url for ajax requests. By controlling this parameter, injection attacks are implemented.

Thank you

Thanks for your reference to nyannyannyan and gerionsecurity.com.