Detailed explanation of js same origin policy_javascript skills

This article analyzes the js same origin strategy in more detail. Share it with everyone for your reference. The details are as follows:

Concept: The same origin policy is an important security metric for client-side scripts (especially Javascript). It first came out of Netscape Navigator2.0, and its purpose is to prevent a document or script from being loaded from multiple different sources.

The same origin here refers to: the same protocol, the same domain name and the same port.

Essence:

The essence of it is simple: it considers trusted content loaded from any site to be unsafe. When scripts that are mistrusted by the browser are run in a sandbox, they should only be allowed to access resources from the same site, not those from other sites that may be malicious.

Why is there a same-origin restriction?

Let’s give an example: For example, a hacker program uses IFrame to embed the real bank login page on his page. When you log in with your real username and password, his page can be read through Javascript. The content in the input in your form, so that the user name and password can be easily obtained.

Ajax application:

This security limitation is broken in Ajax applications.

In ordinary Javascript applications, we can modify the href of Frame or the src of IFrame to achieve cross-domain submission in GET mode, but we cannot access the content in cross-domain Frame/IFrame.

Ajax uses XMLHTTP for asynchronous interaction. This object can also interact with remote servers. What’s even more dangerous is that XMLHTTP is a pure Javascript object. This interaction process is carried out in the background. perceived by the user. Therefore, XMLHTTP has actually broken through the original security limitations of Javascript.

If we want to take advantage of the refresh-free asynchronous interaction capabilities of XMLHTTP, but are unwilling to blatantly break the security policy of Javascript, the alternative is to add strict same-origin restrictions to XMLHTTP. Such a security policy is very similar to Applet's security policy. The limitation of IFrame is that it cannot access data in cross-domain HTMLDOM, while XMLHTTP fundamentally limits the submission of cross-domain requests .

Browser support: IE actually opens two backdoors for this security policy. One is: it assumes that your local files will naturally know what content will be accessed, so any of your local files accesses external data. You won't receive any warning. Another is: when the script of the website you visit intends to access cross-domain information, it actually just pops up a dialog box to remind you. If a fraudulent website uses this method to provide you with a fake page, and then helps you log in to the real bank server remotely through XMLHTTP. Only one of the 10 users was confused and clicked OK. Their account theft was successful! Think about it, how dangerous this is!

FireFox does not do this. By default, FireFox does not support cross-domain XMLHTTP requests at all, and does not give hackers such an opportunity.

Avoid same-origin strategy:

JSON and dynamic script tags