CORS
Last updated
Last updated
The CORS (Cross-origin resource sharing) standard is needed because it allows servers to specify who can access its assets and which HTTP request methods are allowed from external resources.
To check CORS misconfigurations of specific domain:
python cors_scan.py -u example.com -v
To check CORS misconfigurations of specific URL:
python cors_scan.py -u http://example.com/restapi -v
python theftfuzzer.py -d 'http://example.com/api/data'
python3 corsy.py -i urls.txt
echo "https://example.com" | ./CorsMe
cat http_https.txt | ./CorsMe -t 70 -wildcard -header "Cookie: Session=12cbcx...."
cat http_https.txt | ./CorsMe -t 70 -wildcard -header "Cookie: Session=12cbcx...." -method "POST"
This will send the request with cookies and requires “Access-Control-Allow-Credentials = true” in response headers for this.responseText to be readable.
For local testing the vulnerability, for example, if it is post-domain wildcard, modify /etc/hotst:
If the origini is reflected in the Access-Control-Allow-Origin and it returns a good response is vulnerable.
Some applications that support access from multiple origins do so by using a whitelist of allowed origins.
Some organizations decide to allow access from all their subdomains (including future subdomains not yet in existence).
Examples:
normal-website.com (allowed) --> hackersnormal-website.com (registered by attacker)
normal-website.com (allowed) --> normal-website.com.evil-user.net (registered by attacker)
It is also reflected in the Access-Control-Allow-Origin header.
In this situation, an attacker can use various tricks to generate a cross-origin request containing the value null in the Origin header. This will satisfy the whitelist, leading to cross-domain access.
Even "correctly" configured CORS establishes a trust relationship between two origins. If a website trusts an origin that is vulnerable to cross-site scripting (XSS), then an attacker could exploit the XSS to inject some JavaScript that uses CORS to retrieve sensitive information from the site that trusts the vulnerable application.
Could be exploited:
If an application employs HTTPS, but whitelists a trusted subdomain that is using plain HTTP, an attacker who is in a position to intercept a victim user's traffic can exploit the CORS configuration to compromise the victim's interaction with the application.