What is homology

Same-origin means that the protocol, domain name, and port are the same. Even if two different domain names point to the same IP address, they are not same-origin.

Protocol, subdomain name, master domain name, port numberIf any of them are different, they count as different domains. Requests for resources between different domains are “cross-domain.” The common cross-domain scenarios are as follows: Note:

It’s easy to confuse abc.com and abc.comwww.abc.comWe often refer to WWW as the main domain, but that is not the norm. WWW is really just a subdomain of abc.com.

Same-origin-policy (SOP)

Netscape introduced the same origin policy into the browser in 1995. It is the core and most basic security function of the browser. Without the same origin policy, the browser is vulnerable to XSS and CSFR attacks.

Browsers use the same origin policy, which prevents a page from loading or executing any script from a different source than its own without explicit authorization.

The same origin policy is classified into the following three types:

  1. DOM same-origin policy: Operations on DOM of different source pages are prohibited. The main scenario here is iframe cross-domain. Iframes of different domain names are restricted to each other (for example, the page of a malicious website embedded with the login page of a bank through iframe (the two sources are different). If there is no same-origin restriction, Javascript scripts on malicious web pages can get the user’s username and password when they log in to the bank.)
  2. XMLHttpRequest same-origin policy: Disallows the use of XHR objects to make HTTP requests to server addresses of different sources (ajax included).
  3. Cookie, LocalStorage, IndexedDB and other stored content same-origin policy: Cookies and LocalStorage that do not belong to the same source cannot be accessed in JS.

Specifically, cookie and LocalStorage in control of which sources can access the problem is still subtle differences, the parent domain in setting the cookie can be set to allow sub-domain access to the cookie, and the cookie is only associated with the domain name and path, If it is the same domain name, different ports of the source still share the Cookie under the same domain name, and LocalStorage is managed by the source unit, independent of each other, different sources cannot access the content in LocalStorage.

But the same-origin policy leaves some “back doors” :

  1. Links, redirects, and form submissions in pages are not restricted by the same origin policy (ajax form submissions are not allowed without authorization, but regular forms can cross domains directly).
  2. <script>, <img>, <link>These tags with SRC attributes can load cross-domain resources. However, browsers restrict JavaScript permissions so that it cannot read and write loaded content.

Conclusion:

The same origin policy limits the following items:

  • Cookie, LocalStorage, IndexedDB and other stored content
  • DOM and JS objects are not available
  • After the AJAX request is sent, the result is intercepted by the browser

But there are three tags that allow cross-domain loading of resources:

  • <img src=XXX>
  • <link href=XXX>
  • <script src=XXX>

Purpose of the same Origin policy

The purpose of the same origin policy is to ensure security in browser browsingCopy the code

Let me give you two quick examples

(1) If there is no DOM same-origin policy, that is, iframes in different domains can access each other, then hackers can attack as follows:

  1. Create a fake website with iframe nested inside a bank’s website, mybank.com.
  2. Adjust the width and height of the iframe to the entire page, so that users come in just like the bank’s website, except for the domain name.
  3. At this time, if the user enters the account password, our main website can access the DOM node of Mybank.com across the domain and get the account password of the user.

(2) If XMLHttpRequest has the same origin policy, then hackers can carry out CSRF (cross-site request forgery) attacks:

  1. The user logs in to his bank page, mybank.com, and the user id is added to the cookie facing the user on the bank page.
  2. The user browses the malicious page evil.com and executes the malicious AJAX request code on the page.
  3. Evil.com makes an AJAX HTTP request to Mybank.com, and the browser sends the cookie corresponding to MyBank.com by default.
  4. The bank page extracts the user id from the cookie sent, verifies that the user is correct, and returns the request data in response. At this point, the data is leaked, and because Ajax is executing in the background, the user is unaware of the process.

Note:

  • Cookies are sent by the browser based on the page you requested, regardless of the page from which the request was sent. For example, AFTER I visited a.com, I obtained the cookie of A.COM, and then I visited Q.com. Due to the limitation of cookie field, the browser will not carry the cookie of A.COM when requesting Q.com. However, when Q.com has a request to A.com, the browser will automatically bring the cookie of A.com in this request.

  • Cross-domain does not mean that the request cannot be sent out, the request can be sent out, the server can receive the request and return the result normally, but the result is blocked by the browser.

You may be wondering why Ajax can’t make cross-domain requests when you can make them with forms. Because ultimately, cross-domain is about preventing the user from reading content under another domain name, Ajax can get a response that the browser considers unsafe, so it blocks the response. But the form doesn’t get new content, so it can make a cross-domain request. It also shows that cross-domain does not prevent CSRF completely, because the request is made after all.

(1) Cross-domain reads: The same-origin policy does not allow this to happen. If possible, you can use JS to read the DOM element of the page embedded in the iframe to obtain sensitive information

(2) Cross-domain writing: The same origin policy does not prevent such operations, such as sending POST requests to addresses of different sources, but this is only allowed on normal forms (and without a CSRF token or validation referer), and is not allowed on Ajax by default. The CSRF request can be made using Ajax if it is allowed casually

(3) Cross-domain embedding: This is allowed by default. We can embed iframe from one source to another, but if we want to limit this, we can set the x-frame-options header so that pages with this header can be embedded in different sources

Four, reference

A Brief Introduction to nine Cross-domain Implementations of Front-end “Source” Correlation (Full version)