The homologous strategy of JavaScript

The content of this article source : Https://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy

(Since I cannot open this link locally, it is reproduced here.) For everyone to study together)

The same-origin policy restricts the way in which a source (origin) is loaded or scripted with resources from other sources (origin).

Same-origin definition

If two pages have the same protocol (protocol), the port (if specified), and the host, then the two pages belong to the same source (origin).

The following table shows an example of relative http://store.company.com/dir/page.html homology detection:

Url	Results	Reason
Http://store.company.com/dir2/other.html	Success
Http://store.company.com/dir/inner/another.html	Success
Https://store.company.com/secure.html	Failed	Different protocols
Http://store.company.com:81/dir/etc.html	Failed	Different ports
Http://news.company.com/dir/other.html	Failed	Host name is different

See Origin definition for File:urls.

Source Inheritance

Content from About:blank,javascript: And Data:urls inherits the source specified by the document to which it is loaded, because their URL itself does not specify any information about its own source.

IE Special case

There are two major differences between IE in dealing with the same-origin strategy.

• Credit scope (Trust Zones): Two highly trusted domain names, such as the company domain name (corporate domains), do not comply with the limitations of the same-origin policy.
• Port: IE does not add port numbers to the components of the same-origin policy, so http://company.com:81/index.html and http://company.com/index.html belong to the same origin and are not subject to any restrictions.

These exceptions are non-standard and other browsers do not support it, but will help develop applications based on window RT ie.

Change Source

The page can change its source, but it is subject to some limitations. The script can set the value of Document.domain to a suffix of the current field

There is one exception to the same-origin policy, where the script can set the value of Document.domain to a suffix of the current field, and if so, the short domain will be used as the basis for subsequent homology detection. For example, suppose a script in http://store.company.com/dir/other.html executes the following statement:

Document.domain = "company.com";

After this statement is executed, the page will successfully pass the homologous detection of the http://company.com/dir/page.html. In the same vein, company.com cannot set Document.domain to othercompany.com.

The browser saves the port number separately. Any assignment operation, including document.domain = Document.domain, will overwrite the original port number with a null value. So the script for the company.com:8080 page cannot communicate with company.com just by setting Document.domain = "company.com". The value must be assigned with the upper port number to ensure that the port number is not NULL.

Note: Using Document.domain to secure the subdomain access to its parent domain requires both the subdomain and the parent domain's document.domain to be set to the same value. This must be done, even if the parent domain is simply set to its original value. Failure to do so may result in authorization errors.

Cross-domain network access

The same-origin policy controls interactions between different sources, such as when using XMLHttpRequest or tags, which are constrained by the same-origin policy. Interactions are usually divided into three categories:

• Cross-domain write operations (Cross-origin writes) are generally allowed. such as links, redirects, and form submissions. A specific few HTTP requests need to be added preflight.
• Cross-domain resource embedding (Cross-origin embedding) is typically allowed. The following examples are shown below.
• Cross-domain read operations (Cross-origin reads) are not normally allowed. However, it is often possible to skillfully read access through embedded resources. For example, you can read the height and width of an embedded picture, call the inline script method, or availability of an embedded resource.

Here are some examples of resources that can be embedded across domains:

• <script src= "..." ></script> tags embed cross-domain scripting. Syntax error messages can only be captured in the same-origin script.
• <link rel= "stylesheet" href= "..." > tags embedded in CSS. Due to the loosely grammatical rules of CSS, the cross-domain of CSS requires a set of correct Content-type message headers. Different browsers have different restrictions: IE, Firefox, Chrome, Safari (skip to cve-2010-0051) and Opera.
• embed images. The supported picture formats include Png,jpeg,gif,bmp,svg,...
• <video> and <audio> embed multimedia resources.
• <object>, <embed> and <applet> plugins.
• @font the font introduced by-face. Some browsers allow cross-domain fonts (cross-origin fonts), and some require homologous fonts (Same-origin fonts).
• <frame> and <iframe> any resources that are loaded. Sites can use the X-frame-options message header to prevent this form of cross-domain interaction.

Implementing Cross-Domain access

Use Cors for cross-domain access.

Block cross-domain access

• Prevents cross-domain writes, as long as a non-measurable token (CSRF token) is detected in the request, which is called the Cross-site request forgery (CSRF) token. This tag must be used to block the cross-site read operation of the page.
• To prevent cross-site reads of resources, you need to ensure that the resource is not embeddable. Blocking the embedding behavior is necessary because embedded resources typically expose information to it.
• Prevent cross-site embedding, ensuring that your resources cannot be in the embeddable resource format listed above. In most cases, browsers do not adhere to the Conten-type message header. For example, if you embed an HTML document in a <script> tag, the browser still parses the HTML into JavaScript. When your resource was not a entry point to your site, you can also use a CSRF token to prevent embedding.

Cross-domain Scripting API access

JavaScript APIs such as Iframe.contentwindow, Window.parent, window.open, and Window.opener allow documents to be referenced directly to each other. These references add restrictions to access to Window and location objects when the source of the two documents is not the same. You can use Window.postmessage as an alternative to provide communication between documents across domains.

Cross-domain data store access

Data stored in the browser, such as Localstorage and INDEXEDDB, is segmented with the source. Each source has its own separate storage space, and JavaScript scripts in one source cannot read and write to data belonging to other sources.

The Window.name property can be used to temporarily store data that can be accessed across domains.

Cookies use different source definition methods. A page can set a cookie for this domain and any parent domain, as long as the parent domain is not public suffix. Firefox and Chrome Use the public Suffix list to determine whether a domain is a common Suffix. Regardless of which protocol (HTTP/HTTPS) or port number is used, the browser allows the given domain and any of its subdomains (sub-domains) to access the cookie. When setting a cookie, you can use Domain,path,secure, and the http-only tag to qualify its accessibility. When you read a cookie, you don't know where it comes from. Despite the use of secure HTTPS connections, any visible cookie is set using an unsecured connection.

The homologous strategy of JavaScript