> For the complete documentation index, see [llms.txt](https://davidjosearaujo.gitbook.io/notes-mcs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://davidjosearaujo.gitbook.io/notes-mcs/analysis-and-exploration-of-vulnerabilities/xss-cross-site-scripting/same-origin-policy.md).

# 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-face`
* Anything 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.

<figure><img src="/files/Yiv45TZE5vmF5Q7I5PxW" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/oYn4ZKsY0u3bUVJDNcRV" alt=""><figcaption></figcaption></figure>

## 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.