CORS
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.
Tools
- CORScanner
https://github.com/chenjj/CORScanner
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
- theftfuzzer
https://github.com/lc/theftfuzzer
python theftfuzzer.py -d 'http://example.com/api/data'
- Corsy
https://github.com/s0md3v/Corsy
python3 corsy.py -i urls.txt
- CorsMe
https://github.com/Shivangx01b/CorsMe
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"
- CORS*, Additional CORS Checks Burp Addon
https://portswigger.net/bappstore/420a28400bad4c9d85052f8d66d3bbd8
- Basic PoC
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:
Vulnerabilities Exploitation
- Basic Origin Reflection Exploitation
If the origini is reflected in the Access-Control-Allow-Origin and it returns a good response is vulnerable.
- Errors parsing Origin headers
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)
- Whitelisted null origin value
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.
- XSS via CORS trust relationships
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:
- TLS Breaking
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.
Last updated