4.2.3. Same Origin Policy

Introduction The same-origin policy restricts how resources interact between different sources and is an important security mechanism for isolating potentially malicious files.

Whether it is the same origin or not is determined by the URL. The URL consists of the protocol, domain name, port and path. If the protocol, domain name and port of two URLs are the same, it means that they are of the same origin.

4.2.3.1. Same Origin Policy for the file domain

In previous browsers, any two file field URIs were considered to be of the same origin. Any HTML file on the local disk can read any other file on the local disk.

Since Gecko 1.9, files use a more granular same-origin policy, a file can only read another file if the parent directory of the source file is the ancestor directory of the target file.

4.2.3.2. Same Origin Policy for Cookies

Cookies use different source definitions. A page can set cookies for this domain and any parent domain, as long as the parent domain is not a public suffix.

Regardless of the protocol (HTTP/HTTPS) or port number used, browsers allow a given domain and any of its subdomains to access cookies. When setting a cookie, you can use domain / path / secure and http-only tags secure to limit its accessibility.

So https://localhost:8080/ and http://localhost:8081/ cookies are shared.

4.2.3.3. Flash/SilverLight cross domain

There are also cross-domain requirements for various plug-ins of browsers. It is usually by configuring crossdomain.xml on the server to set which domain names the service allows for cross-domain access.

The client will request this file. If it finds that its domain name is in the access list, it will initiate a real request, otherwise it will not send the request.

4.2.3.3.1. Source Changes

The same-origin policy considers domains and subdomains to belong to different domains, e.g. child1.a.com and a.com / child1.a.com and child2.a.com / xxx.child1.a.com and child1.a.com pairs of different origins

For this case, it can be set in two aspects document.domain='a.com' to change its source to realize the communication between any two pages above.

In addition, because the browser saves the port number separately, this assignment will cause the port number to be rewritten as null.

4.2.3.3.2. Cross-Origin Access

The same-origin policy controls interactions between different origins, and these interactions are generally divided into three categories:

• Cross-origin writes are usually allowed

  • links

  • redirect

  • form submission

• Cross-origin embedding is usually allowed

• Cross-origin reads are generally not allowed

Some examples of resources that may be embedded cross-origin are:

• <script src="..."></script> Tags embed cross-domain scripting. Syntax error messages can only be caught in same-origin scripts.

• <link rel="stylesheet" href="..."> Tags are embedded in CSS. Due to the loose syntax rules of CSS, cross-domain CSS requires a correctly set Content-Type header.

• <img> / <video> / <audio> Embedding multimedia resources

• <object> <embed> and <applet> plugins。

• @font-face imported font. Some browsers allow cross-origin fonts, some require same-origin fonts.

• <frame> and <iframe> load any resources。Sites can use the X-Frame-Options header to prevent this form of cross-domain interaction.

4.2.3.4. JSONP cross domain

JSONP uses the cross-domain capabilities of <script> tags to access cross-domain data, and requests a dynamically generated JavaScript script with a callback function name as a parameter.

After the server receives the request, it dynamically generates a script to generate data, and calls the callback function in the code with the generated data as a parameter.

JSONP also has some security issues. For example, when the incoming/returning parameters are directly returned without verification, it will cause XSS problems. When data is given without Referer or Token verification, it may cause data leakage.

In addition, JSONP can legally make some function calls outside the design without setting the whitelist of callback functions, which will introduce problems. This attack is also known as a SOME attack.

4.2.3.5. Cross-Origin Scripting API Access

Javascript APIs such as iframe.contentWindow , window.parent, window.open and window.opener allow documents to refer to each other。These references impose restrictions on access to window and location objects when the two documents have different sources。

window Methods that allow cross-origin access are

• window.blur

• window.close

• window.focus

• window.postMessage

window Properties that allow cross-origin access are

• window.closed

• window.frames

• window.length

• window.location

• window.opener

• window.parent

• window.self

• window.top

• window.window

Among window.location read/write is allowed, and other attributes are only allowed to read

4.2.3.6. Cross-Origin Data Store Access

Data stored in the browser, such as localStorage and IndexedDB，is split by source. Each source has its own separate storage space, and Javascript scripts in one source cannot read or write data belonging to other sources.

4.2.3.6.1. CORS

CORS is a W3C standard, the full name is Cross-origin resource sharing. Through this standard, browsers can be allowed to read cross-domain resources.

4.2.3.7. Common request headers

• Origin

  • The origin site URI of the preflight request or the actual request, this field will be sent by default for browser requests

  • Origin: <origin>

• Access-Control-Request-Method

  • Declare the method used by the request

  • Access-Control-Request-Method: <method>

• Access-Control-Request-Headers

  • Declare the header fields used by the request

  • Access-Control-Request-Headers: <field-name>[, <field-name>]*

4.2.3.8. Common return headers

• Access-Control-Allow-Origin

  • Declare the origin out-of-domain URIs that are allowed to access

  • Wildcards are not allowed for requests with credentials *

  • Access-Control-Allow-Origin: <origin> | *

• Access-Control-Expose-Headers

  • Declares that exposed headers are allowed

  • e.g. Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header

• Access-Control-Max-Age

  • Declare cache time

  • Access-Control-Max-Age: <delta-seconds>

• Access-Control-Allow-Credentials

  • Whether the declaration is allowed to be brought in the request

  • Access-Control-Allow-Credentials: true

• Access-Control-Allow-Methods

  • Declare allowed access methods

  • Access-Control-Allow-Methods: <method>[, <method>]*

• Access-Control-Allow-Headers

  • declare allowed headers

  • Access-Control-Allow-Headers: <field-name>[, <field-name>]*

4.2.3.9. Defense Recommendations

• Do not enable CORS unless necessary

• Define a detailed whitelist, do not use wildcards, configure only the required headers

• configuration Vary: Origin header

• Do not use unless necessary Access-Control-Allow-Credentials

• Limit cache time

4.2.3.9.1. Block Cross-Origin Access

To prevent cross-origin write operations, you can detect the flag CSRF token in the request , this flag is called the Cross-Site Request Forgery (CSRF) flag.

Prevent cross-site reading of resources, because embedding resources usually expose information, you need to ensure that resources are not embeddable. But in most cases browsers will not honor the Content-Type message headers. For example, if you specify the <script> tag in the HTML document, the browser will try to parse the HTML into JavaScript.