0 * 00 background
When it comes to browser homology, we are all familiar with it. Client scripts in different domains cannot read or write to each other's resources. But in practice, there are some scenarios that need to be read and written across domains, so there are some hack methods to cross domains. For example, to be a proxy in the same domain, json-p, etc. However, these methods are flawed and can not achieve cross domain reading and writing perfectly. Therefore, under the XMLHttpRequest V2 standard, a CORS (cross origin resource sharing) model is proposed to provide safe and convenient cross domain read-write resources. At present, the mainstream browsers support CORS.
0 × 01 technical principle
CORS defines two kinds of cross domain requests: simple cross domain request and non simple cross domain request. When a cross domain request sends a simple cross domain request including: the request method is head, get, post; the request header has only four fields, accept, accept language, content language, last event ID; if content type is set, its value can only be application / x-www-form-urlencoded, multipart / form data, text / plain. It's awkward to say. Simple means that a white list has been set up. Only those who meet this requirement are simple requests. Other non conformities are non simple requests.
The reason for this classification is that browsers have different processing mechanisms for simple and non simple requests. When we need to send a cross domain request, the browser will first check the request. If it meets the simple cross domain request mentioned above, the browser will send the request immediately. If the browser checks 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 has a preflight, and the server verification process. The browser first sends a pre check request for the options method. The following is an example. If the pre check passes, the request will be sent; otherwise, the cross domain request will not be rejected.
The following is a detailed analysis of the control methods for implementing secure cross domain requests. Let's first look at the pre inspection process for non simple requests. The browser first sends a request for the options method. With the following fields:
Then if the server is configured with CORS, the corresponding fields will be returned. The specific meaning of the fields will be explained in the returned results.
Then the browser judges whether to send the non simple request according to the return value of the server. The simple request was sent directly as mentioned before, but an additional origin field indicates the source of the cross domain request. After the server finishes processing the request, the following control fields will be added to the returned result:
The browser then returns these control fields of the result to decide whether to open the result to the client script to read or to mask it. If the server does not configure CORS and there is no control field for the returned result, the browser will block the reading of the returned information by the script.
0 × 02 potential safety hazard
Everyone pay attention to this process. When the server receives the cross domain request, it does not verify first, but processes the request first. So in a way. The implementation of cross domain write resources on CORS enabled browsers breaks the traditional strategy of cross domain read and write resources.
Another is to set access control allow origin to allow cross domain requests from all domains if the application is lazy. Then the security mechanism of CORS is almost invalid. But don't be happy too early. In fact, there is a good limitation in the design. The request sent by XMLHttpRequest needs to use "with credentials" to bring cookies. If a target domain is set to allow cross domain requests of any domain, and the request carries cookies, the request is illegal. (that is, if you need to implement cross domain requests with cookies, you need to explicitly configure the domain that allows the source, and it is illegal to use any domain configuration) the browser will block the returned results. JavaScript can't get the returned data. This is the last line of defense for the CORS model. If there is no such limitation, JavaScript can obtain the CSRF token in the returned data, as well as various sensitive data. This restriction greatly reduces the risk of CORS.
0 × 03 attack model
In terms of thinking, there are two types of attacks. One is to embed cross domain request on the webpage controlled by the attacker. The user accesses the link and executes the cross domain request, so as to attack the target, such as accessing the sensitive resources of the intranet. Another is that the normal web page is embedded in the cross domain request of the attacker to control the page, thus hijacking the user's session.
0 × 04 attack scenario
First look at the attack scenario of the first idea:
1. Complex CSRF. Traditional CSRF uses HTML tags and forms to send requests. There is no way to implement some complex steps of CSRF, such as simulation shopping, adding shopping cart first, settlement, filling in information, etc. For example, upload files. For details, please refer to uploading files with CSRF
2. Access intranet sensitive resources. This can be achieved under certain conditions. For example, the intranet server configuration
When a user visits a malicious web page, he executes a request to the intranet server 192.168.1.123/password.txt. After receiving the server's return, the script sends the content to the attacker's server.
The second scenario:
1. Interactive XSS. Refer to the shell of the future tool mentioned in the attack techniques of exposing HTML5. Through CORS, we can bypass some anti session hijacking methods, such as HTTP only limited cookies, session ID binding IP address, etc., and hijack user session.
2. When programming apes write Ajax requests, they have no strict restrictions on the target domain. It's a bit like a URL jump. There was a case on Facebook. JavaScript requests Ajax through the parameters in the URL. The injection attack is implemented by controlling this parameter.
0 x 05 thanks
Thank you for referring to the articles of nyannyannyan and geronsecurity.com.