Deep Exploration of homologous policy and multi-page communication and cross-domain request

For the security of the Web, the main browsers now follow the same-origin policy. What are the specifications of the homologous strategy? How do you embody the security effect?
One of the primary objectives of a personal summary of homologous strategies is:

Blocks that can transmit information outside of the module (such as JavaScript) get resources from different sources, do not get access to the source, and prevent the disclosure of the resources and information therein .

It is important to note that the same-origin policy blocks the acquisition of cross-domain resources, rather than blocking cross-domain requests, the request can be issued normally, but the returned content is blocked from getting the JS script to get

For JavaScript, and see a few intuitive phenomena:
1, one page of JavaScript can get to other pages of window. However, in the case of non-homology, only the window's few properties and methods can be accessed.
There are several ways to access attributes at different sources:
Method
Window.blur
Window.close
Window.focus
Window.postmessage
Property
Window.closed Read only.
Window.frames Read only.
Window.length Read only.
Window.locationread/write.
Window.opener Read only.
Window.parent Read only.
Window.self Read only.
Window.top Read only.
Window.windowread only.
Some browsers may allow access to a few more property methods. But important document,localstorage and so on must be unable to read and write.
The page can set its own document.domain, opening scripts for other parts of the domain to read and write to its own document, Localstorage, and so on.
On the basis of homology, there is no limit.
2, <script>, , <iframe>, <link> and other tags can load content across domains, but cannot use these tags to send externally loaded content.
3, JS script can not get to the above tag loaded back content, it will not be able to send the content, can only get the content by the browser after parsing the browser based on the need to expose information (such as IMG width,onload, etc.).

A non-intuitive phenomenon:
1, Ajax can use the user identity to request the content of different sources, but the same-origin policy to prevent the content of the request back to JavaScript flow, so can not be disclosed to the user's browser.

This phenomenon can set up the localhost test, the background to receive the request and normal response, but the browser shows that there is no cross-domain resource sharing, unable to access the returned content

How do you embody the security effect?
Imagine a scenario where the user opens the Www.bank.com/bank.html and opens the www.evil.com/evil.html in another tab.
At this time, under the same-Origin policy, the JS script on the evil.html page does not have access to important resources such as document,localstorage, which operate bank.html pages.
Evil.html can use scripts to create IFRAME,IMG, Script to load bank.com Resources, these resources are loaded back by default by the browser to parse or render, scripts still can not get loaded back content, only the browser based on the need to expose information (such as IMG width,onload, etc.).
evil.html script can use Ajax directly to load the resources on the bank.com, Ajax requests can be sent and returned correctly, but parked in the browser, the same-origin policy to prevent the request back to the evil.html on the flow of the script
At this point the evil.html script has no access to information about the user.
In particular, send requests from bank.html or evil.html to bank.com/charge.html,
The two cookies are the same, but the referer of the HTTP request header is the same, and the backend only determines that the cookie/session is the real user's request. A cross-domain request forgery attack (CSRF) is formed.
For this, bank.com back end is not silly, it sent a unique identification in the bank.html page, bank.html to charge.html request also with a unique identity, the back end not only Judge Referer, It was also deliberately checked to see that the identities received and the unique identities sent beforehand were consistent.
Evil.html cannot access bank.html, so it cannot get a unique identity and cannot forge and bank.html the same request.
At this point, Evil.html's script was nothing, unable to obtain and disclose information, and could not forge requests.

Combined with the above phenomenon, it can be concluded that the same-origin strategy to standardize the resources and information JavaScript can access, so users even accidentally browse to the bad Web page, there is a certain security.

Under the same Origin policy, JavaScript is limited to the communication between multiple pages and the resource acquisition of multiple domains, and the following is a brief introduction to some reasonable cross-domain methods under the homologous policy.
For multi-page communication
1. Set Document.domain+iframe
2, Window.name
3, Window.postmessage,window.localstorage
For cross-domain resource acquisition
4. Cross-domain resource sharing cors (Cross-origin Resource sharing)
5, JSONP
6, WebSockets
The summary is that these methods are a to access B, b page actively open access, or B server itself according to the request information to determine whether to open a request and with a to return the appropriate response, so a can cross-domain access to resources.
Personally feel that the way the background agent is not cross-domain to the front end, so it is not due to the above cross-domain method.

Refer to the following articles for a detailed description of the articles and cross-domain methods:
JavaScript cross-domain Summary and solution http://www.cnblogs.com/rainman/archive/2011/02/20/1959325.html
Discussion on WEB-JSONP and homologous strategy http://www.cnblogs.com/huangjacky/p/4001073.html
Homologous policy and cross-domain access http://blog.csdn.net/shimiso/article/details/21830313
Homologous strategy and bypass http://www.freebuf.com/articles/web/65468.html
Browser homologous policy and its avoidance method http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html

Interested can look at the origin of the policy comparison of the official introduction
W3c:https://www.w3.org/security/wiki/same_origin_policy
Wiki:https://en.wikipedia.org/wiki/same-origin_policy
Mdn:https://developer.mozilla.org/en-us/docs/web/security/same-origin_policy

Deep Exploration of homologous policy and multi-page communication and cross-domain request