Incorrect Access-Control Headers
Play Labs on this vulnerability with SecureFlag!
Description
The Same Origin Policy (SOP) of web browsers restricts web pages from making cross-origin requests (fetching resources from a different domain) by default to prevent cross-site attacks.
Access-Control headers can explicitly allow specific cross-origin requests by specifying the allowed origin, methods, and headers. They will enable the implementation of Cross-Origin Resource Sharing (CORS) ads to bypass the same-origin policy enforced by default. It is important to remember that the policy cannot stop fetching a specific resource, i.e., performing an initial HTTP request; it simply forbids the requested origin from reading the response.
Unless otherwise specified, a specific web page cannot fetch and use resources from another origin. While this is standard practice and useful to mitigate other exposures that might affect the user experience, there may be times when it is needed to relax such constraints - for example, a publicly available API designed to be used by unknown origins.
But the devil is in the details here, and misconfigurations might arise, in which a too lax (read, completely open) restriction on the allowed origins is used in place of a careful set of allowed entries.
Impact
Allowing unexpected origins to fetch resources (including performing non-idempotent actions) from a backend server can have various impacts depending on the scenario at hand. It ranges from having zero impact in practice to information leakage and phishing.
Prevention
The recommendation is to never use a wildcard * in the Access-Control-Allow-Origin header, which results in a completely disabled same-origin policy (yet cookies won’t go through); instead, the proper origin should be used. In case there are several allowed origins, it is possible to implement a dynamic CORS policy that returns the appropriate Access-Control-Allow-Origin header according to the Origin header present in the request (having the care to reply with the Vary: Origin header as to indicate that the response will vary according to the client Origin header).
Testing
Verify that the Cross-Origin Resource Sharing (CORS) Access-Control-AllowOrigin header uses a strict allow list of trusted domains and subdomains to match against and does not support the “null” origin.
- OWASP ASVS: 14.5.3