Same Origin Policy
Sites may require external resources (Cross Origin Resources).
Javascripts, Images, Styles.
However, this should be controlled.
Current site perspective: where my resources are being loaded from?
Images may be remote, JS should be local, as well as styles...
Other sites: who is accessing my resources?
I do not want to be spreading malware (act as a storage for Stored XSS).
Web servers may state a header that sets the Same Origin Policy.
What is Same Origin Policy?
SOP restricts how a document or script loaded from one origin can interact with a resource from another origin.
Origin is permitted to send data to another origin but not read.
Interactions between origins are placed in three categories:
Cross origin writes (redirects, links, form action etc.).
Cross origin embedding (html tag with src/hrefs).
Cross origin reads (not allowed without CORS etc.).
Cross Origin Embedding
JavaScript
<script src="..."></script>CSS with
<link rel="stylesheet" href="...">Images with
<img>Media files with
<video>and<audio>tags.Plug-ins with
<object>,<embed>and<applet>Fonts with
@font-faceAnything with
<frame>and<iframe>
Why is CORS needed?
For legitimate and trusted requests to gain access to authorized data from other domains.
Think cross application data sharing models.
Allows data to be exchanged with trusted sites while using a relaxed Same Origin policy mode.
Application APIs exposed via web services and trusted domains require CORS to be accessible over the SOP.
CORS
Requests
Preflight is not needed if:
Request is a HEAD/GET/POST via XHR.
No Custom headers.
Body is text/plain.
Server responds with a CORS header.
Browser determines access.
Neither the request, nor response contain cookies.
Headers
Simple Request.
Origin: Header set by the client for every CORS request.
Value is the current domain that made the request.
Access-Control-Allow-Origin.
Set by the server and used by the browser to determine if the response is to be allowed or not.
Can be set to * to make resources public (bad practice!).
Insecurity
Several security issues arise from the improper implementation of CORS.
Most commonly using a universal allow notation (*) in the server headers.
Clients should not trust the received content completely.
Eval or render content without sanitization which could result in misplaced trust.
The application that allows CORS may become vulnerable to CSRF attacks.
Prolonged caching of Preflight responses could lead to attacks arising out of abuse of the Preflight Client Cache.
Access control decisions based on the Origin header could result in vulnerabilities as this can be spoofed by an attacker.
Misplaced Trust
Data exchange between two domains is based on trust.
If one of the servers involved in the exchange of data is compromised, then the model of CORS is put at risk.
Scenarios?
An attacker can compromise site A and host malicious content, knowing site B trusts the data that site A sends to site B.
Access Control based on Origin
The Origin header indicates that the request is from a particular domain, but does not guarantee it.
Header can be controlled by the attacker.
Spoofing the Origin header allows access to the page if access is based on this header.
Scenarios?
An attacker sets the Origin header to view sensitive information that is restricted.
Using cURL to set a custom origin header:
curl --header 'origin:http://someserver.com'
Caching of Preflight responses
The Access-Control-Max-Age header is set to a high value, allowing browsers to cache Preflight responses.
It’s very important for performance reasons.
But caching the preflight response for longer duration can pose a security risk.
If the access-control policy is changed on the server the browser would still follow the old policy available in the Preflight Result Cache.
Scenario:
During updates to sites, the access policy will be out of sync until the cache expires.
Universal Allow
Setting the 'Access-Control-Allow-Origin' header to *
Effectively turns the content into a public resource, allowing access from any domain.
Very common during development, and somewhat during production.
Scenarios?
An attacker can steal data from an intranet site that has set this header to * by enticing a user to visit an attacker controlled site on the Internet.
An attacker can perform attacks on other remote apps via a victim’s browser when the victim navigates to an attacker controlled site.
Last updated
