Learn Pentesting: Manual Testing for CORS – Arbitrary Origin Trusted

Cross-Origin Resource Sharing (CORS) is a powerful browser mechanism designed to relax the strict same-origin policy, enabling controlled access to resources on a web server from external domains. However, misconfigurations in CORS can introduce serious vulnerabilities—one being the “Arbitrary Origin Trusted” flaw. In this post, we’ll perform a technical deep-dive into manually testing for this vulnerability during web-application penetration tests.

1. Understanding CORS and Its Role in Web Security

Modern browsers enforce the same-origin policy to restrict how a document or script loaded from one origin can interact with a resource from another origin. CORS provides a safe way for web servers to specify trusted domains by adding specific headers in their responses, such as:

Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Allow-Credentials

When properly configured, these headers ensure that only whitelisted domains can access sensitive resources. However, if the server simply echoes back the Origin header from the request without validating it, an attacker may exploit this behavior to perform unauthorized cross-origin requests.

2. The “Arbitrary Origin Trusted” Vulnerability Explained

What Is It?

The Arbitrary Origin Trusted vulnerability occurs when the server misconfigures its CORS policy, typically by dynamically reflecting the incoming Origin header in the Access-Control-Allow-Origin response header. This behavior effectively “trusts” any origin, allowing a malicious domain (e.g., http://evil.com) to access sensitive data.

Why Is It Dangerous?

Bypassing Same-Origin Policy: The attacker can trick the browser into sending cross-origin requests and accessing confidential data.
Credential Exposure: If the server also sets Access-Control-Allow-Credentials: true, the risk increases dramatically, as credentials (cookies, HTTP authentication, etc.) may be exposed to untrusted origins.
Data Exfiltration: Attackers can leverage this vulnerability to exfiltrate data, perform unauthorized actions, or further compromise the application.

3. Manual Testing Techniques

Manual testing for CORS vulnerabilities involves sending requests with custom Origin headers and analyzing the responses for misconfigurations. Below are several methods and examples.

3.1 Testing with cURL

cURL is an excellent tool to simulate HTTP requests with custom headers. The following command sends a GET request with a malicious origin header:

curl -i -H "Origin: http://evil.com" http://target.com/api/data

What to Look For:
Check the response headers. If you see:

Access-Control-Allow-Origin: http://evil.com

this indicates that the server is echoing back the provided origin, potentially making it vulnerable to arbitrary origin trust.

3.2 Testing with Python’s Requests Library

For a more programmable approach, use Python to send a request with a custom Origin header:

import requests

url = "http://target.com/api/data"
headers = {"Origin": "http://evil.com"}
response = requests.get(url, headers=headers)

print("Response Headers:")
for key, value in response.headers.items():
    print(f"{key}: {value}")

Explanation:

This script sends a GET request to the target URL with Origin: http://evil.com.
Review the output for the Access-Control-Allow-Origin header. A matching value indicates that the server may be vulnerable.

3.3 Testing via the Browser (JavaScript Example)

Browsers enforce CORS policies, so you can create an HTML page to test the vulnerability. Save the following as test.html and open it in your browser:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>CORS Vulnerability Test</title>
</head>
<body>
  <script>
    fetch("http://target.com/api/data", {
      method: "GET",
      headers: { "Origin": "http://evil.com" }
    })
    .then(response => {
      console.log("Response Headers:");
      for (let [key, value] of response.headers.entries()) {
        console.log(`${key}: ${value}`);
      }
      return response.text();
    })
    .then(data => console.log("Response Body:", data))
    .catch(error => console.error("Error:", error));
  </script>
</body>
</html>

How It Works:

The script sends a fetch request with a custom Origin header.
Open your browser’s developer console to inspect the response headers and body.
If the Access-Control-Allow-Origin header matches the injected origin (http://evil.com), it’s a strong indicator of misconfiguration.

4. Advanced Testing Considerations

4.1 Preflight Requests

Some requests (especially those that are non-simple, such as those using custom headers or methods like PUT/DELETE) trigger a preflight request (an HTTP OPTIONS request). It’s important to test how the server handles these:

curl -i -X OPTIONS -H "Origin: http://evil.com" -H "Access-Control-Request-Method: GET" http://target.com/api/data

Examine the response for Access-Control-Allow-Methods and Access-Control-Allow-Headers to understand the server’s CORS policy.

4.2 Using Proxy Tools

Tools like Burp Suite or OWASP ZAP are invaluable for manual testing:

Intercept and Modify: Capture requests from your browser and modify the Origin header on the fly.
Automate Testing: Use Burp’s repeater functionality to systematically test various endpoints and header combinations.

4.3 Credentialed Requests

If the application supports cookies or other credentials, test for combined misconfigurations:

curl -i -H "Origin: http://evil.com" --cookie "session=abc123" http://target.com/api/data

Additionally, verify if the server returns:

Access-Control-Allow-Credentials: true

If credentials are allowed alongside an echoed origin, the vulnerability becomes even more critical.

5. Interpreting Results and Mitigation Strategies

Interpreting Test Results

Vulnerable Behavior: If the server echoes back the arbitrary Origin value (e.g., http://evil.com), it is likely vulnerable.
Properly Configured Server: A secure server should either return a fixed whitelist of allowed origins or reject the request with a proper error message if the origin is not trusted.

Mitigation Strategies

While this article focuses on manual testing, it’s important to note remediation steps:

Validate Incoming Origins: Ensure that only predefined, trusted origins are accepted.
Avoid Dynamic Reflection: Do not simply echo the Origin header; instead, implement strict checks.
Use Framework-Specific Best Practices: Many frameworks provide secure defaults for CORS configuration. Leverage these wherever possible.

Conclusion

Manual testing for CORS misconfigurations—especially the Arbitrary Origin Trusted vulnerability—is a crucial skill for penetration testers. By understanding the underlying mechanics of CORS and applying systematic testing approaches with tools like cURL, Python, and browser-based scripts, security professionals can identify potential flaws that might otherwise be exploited by attackers.

This deep dive should serve as a detailed reference for testing CORS vulnerabilities and help you incorporate rigorous security assessments into your pentesting workflow. Remember, secure CORS implementation is not just about functionality—it’s about maintaining the integrity and confidentiality of your web applications.

Happy testing, and stay secure!