Suppose an application that rigorously employs HTTPS also whitelists a trusted subdomain that is using plain HTTP. Breaking TLS with poorly configured CORS Then an attacker who finds an XSS vulnerability on could use that to retrieve the API key, using a URL like: 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. Location='/log?key='+this.responseText ĪPPRENTICE CORS vulnerability with trusted null origin Exploiting XSS via CORS trust relationshipsĮven 'correctly' configured CORS establishes a trust relationship between two origins. Req.open('get','/sensitive-victim-data',true) For example, this can be done using a sandboxed iframe cross-origin request of the form: This will satisfy the whitelist, leading to cross-domain access. In this situation, an attacker can use various tricks to generate a cross-origin request containing the value null in the Origin header. For example, suppose an application receives the following cross-origin request: Some applications might whitelist the null origin to support local development of the application. Browsers might send the value null in the Origin header in various unusual situations: The specification for the Origin header supports the value null. Any mistakes in the implementation can lead to access being granted to unintended external domains.įor example, suppose an application grants access to all domains ending in:Īn attacker might be able to gain access by registering the domain:Īlternatively, suppose an application grants access to all domains beginning withĪn attacker might be able to gain access using the domain: These rules are often implemented by matching URL prefixes or suffixes, or using regular expressions.

And some applications allow access from various other organizations' domains including their subdomains. Some organizations decide to allow access from all their subdomains (including future subdomains not yet in existence). Mistakes often arise when implementing CORS origin whitelists. The application checks the supplied origin against its list of allowed origins and, if it is on the list, reflects the origin as follows: For example, the application receives a normal request like: If the origin appears on the whitelist then it is reflected in the Access-Control-Allow-Origin header so that access is granted. When a CORS request is received, the supplied origin is compared to the whitelist. Some applications that support access from multiple origins do so by using a whitelist of allowed origins. Location='///log?key='+this.responseText ĪPPRENTICE CORS vulnerability with basic origin reflection Errors parsing Origin headers If the response contains any sensitive information such as an API key or CSRF token, you could retrieve this by placing the following script on your website: These headers state that access is allowed from the requesting domain ( ) and that the cross-origin requests can include cookies ( Access-Control-Allow-Credentials: true) and so will be processed in-session.īecause the application reflects arbitrary origins in the Access-Control-Allow-Origin header, this means that absolutely any domain can access resources from the vulnerable domain. For example, consider an application that receives the following request: One way to do this is by reading the Origin header from requests and including a response header stating that the requesting origin is allowed. So some applications take the easy route of effectively allowing access from any other domain. Maintaining a list of allowed domains requires ongoing effort, and any mistakes risk breaking functionality. Some applications need to provide access to a number of other domains. Server-generated ACAO header from client-specified Origin header Their implementation of CORS may contain mistakes or be overly lenient to ensure that everything works, and this can result in exploitable vulnerabilities. Many modern websites use CORS to allow access from subdomains and trusted third parties. Vulnerabilities arising from CORS configuration issues

CORS and the Access-Control-Allow-Origin response header.

Allow cors access control allow origin