CORS or Cross-origin Resource Sharing allows web developers to work around the same-origin policy. The CORS standard describes new HTTP headers which provide browsers and servers a way to request remote URLs only when they have permission.
Cross-origin resource sharing (CORS) allows web-pages to access resources on different domains. A web page may freely embed cross-origin images, stylesheets, scripts, iframes, and videos. Certain “cross-domain” requests, notably Ajax requests, are forbidden by default by the same-origin security policy. CORS defines a way in which a browser and server can interact to determine whether or not it is safe to allow the cross-origin request. It allows for more freedom and functionality than purely same-origin requests, but is more secure than simply allowing all cross-origin requests.
How CORS works ?
Suppose there are two websites site-a.com and site-b.com, now site-a.com try to access site-b.com resources. Then site-a.com sends OPTIONS preflight-request with an Origin HTTP header to site-b.com
site-b.com will respond with an
Access-Control-Allow-Origin header in its response indicating which origin sites are allowed or not. If access allowed then the response header will be :
And if the server does not allow the cross origin requests then then an error page will return.
Access-Control-Allow-Origin header with a wildcard that allows all domains.
A wildcard same-origin policy is appropriate when a page or API response is considered completely public content and it is intended to be accessible to everyone, including any code on any site.
The CORS Misconfiguration is checked by sending preflight requests to target web server. We can use curl for this
curl -I -s -H "Origin: https://evildomain.com" https://targetdoamin.com HTTP/1.1 200 OK Server: gunicorn/19.7.0 Date: Sun, 13 Dec 2020 08:21:23 GMT Connection: close Content-Length: 61752 Access-Control-Allow-Origin: https://evildomain.com Access-Control-Allow-Credentials: true Expires: Sun, 13 Dec 2020 08:21:23 GMT Vary: Authorization, Cookie, Accept-Encoding X-Homer: I like my beer cold, my TV loud and my homosexuals flaming. Cache-Control: no-cache, no-store, must-revalidate, max-age=0 Content-Type: text/html; charset=utf-8 X-gunicorn-server: app02 Strict-Transport-Security: max-age=0; includeSubDomains
At above response we can see the
Access-Control-Allow-Credentials: true , which means that the server allows cookies (or other user credentials) to be included on cross-origin requests.
CORS header is considered misconfigured in three cases
POORLY IMPLEMENTED, BEST CASE FOR ATTACK
Access-Control-Allow-Origin: header will return origin header name sign along with
Access-Control-Allow-Credentials: true header, then this is the best scenario to steal users credentials/data by malicious web pages.
Access-Control-Allow-Origin: https://evildomain.com Access-Control-Allow-Credentials: true
A POC Example from portswigger lab.
POORLY Implemented and Exploitable
Access-Control-Allow-Origin: header will return null with
Access-Control-Allow-Credentials: true header, then this is also exploitable scenario.
Access-Control-Allow-Origin: null Access-Control-Allow-Credentials: true
A POC Example from portswigger lab.
BAD Implementation but Not Exploitable
Access-Control-Allow-Origin: will return
* sign along with
Access-Control-Allow-Credentials: true header
Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true // or Access-Control-Allow-Origin: *
However this misconfigured is not exploitable due to CORS implementation the browser discard the server response (because Access-Control-Allow-Origin is “*” and Access-Control-Allow-Credentials is true).
CORS Misconfig Automation
I wrote a shell script which checks for CORS misconfiguration on web applications.
Github Link : https://github.com/Ajaytekam/CORSMisconfig