Inspired by James Kettle's great OWASP AppSec Europe talk on CORS misconfigurations, we decided to fiddle around with CORS security issues a bit. We were curious how many websites out there are actually vulnerable because of dynamically generated or misconfigured CORS headers.
The issue: CORS misconfigurationCross-Origin Resource Sharing (CORS) is a technique to punch holes into the Same-Origin Policy (SOP) – on purpose. It enables web servers to explicitly allow cross-site access to a certain resource by returning an Access-Control-Allow-Origin (ACAO) header. Sometimes, the value is even dynamically generated based on user-input such as the Origin header send by the browser. If misconfigured, an unintended website can access the resource. Furthermore, if the Access-Control-Allow-Credentials (ACAC) server header is set, an attacker can potentially leak sensitive information from a logged in user – which is almost as bad as XSS on the actual website. Below is a list of CORS misconfigurations which can potentially be exploited. For more technical details on the issues read the this fine blogpost.
|Developer backdoor||Insecure developer/debug origins like JSFiddler CodePen are allowed to access the resource|
|Origin reflection||The origin is simply echoed in ACAO header, any site is allowed to access the resource|
|Null misconfiguration||Any site is allowed access by forcing the null origin via a sandboxed iframe|
|Pre-domain wildcard||notdomain.com is allowed access, which can simply be registered by the attacker|
|Post-domain wildcard||domain.com.evil.com is allowed access, can be simply be set up by the attacker|
|Subdomains allowed||sub.domain.com allowed access, exploitable if the attacker finds XSS in any subdomain|
|Non-SSL sites allowed||An HTTP origin is allowed access to a HTTPS resource, allows MitM to break encryption|
|Invalid CORS header||Wrong use of wildcard or multiple origins,not a security problem but should be fixed|