Details about js same-source policy

Details about js same-source policy

This article gives a detailed analysis of the js same-source policy. Share it with you for your reference. The details are as follows:

Concept: same-origin policy is an important security measure for client scripts (especially Javascript. It was first originated from Netscape Navigator2.0 to prevent a document or script from being loaded from multiple sources.

The same source indicates the same protocol, the same domain name and the same port.

Essence:

Its essence is simple: it thinks that the trusted content loaded from any site is insecure. When the browser is skeptical that the scripts run in the sandbox, they should only be allowed to access resources from the same site, rather than those resources from other sites that may be malicious.

Why is there a single-source restriction?

For example, a hacker program uses IFrame to embed a real bank logon page into his page. When you log on with a real user name and password, the page can read the input content in your form through Javascript, so that the user name and password can be easily obtained.

Ajax applications:

In Ajax applications, this security restriction has been broken through.

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

While Ajax performs Asynchronous interaction through XMLHTTP. This object can also interact with remote server information. What's more dangerous is that XMLHTTP is a pure Javascript Object, this interaction process is performed in the background and is not noticed by users. Therefore, XMLHTTP has actually broken through the original Javascript security restrictions.

If we want to use XMLHTTP's new Asynchronous interaction capability and do not want to openly break through Javascript's security policy, we can choose to add strict same-source restrictions to XMLHTTP. This security policy is similar to the Applet security policy. IFrame does not allow access to data in the Cross-origin HTMLDOM, while XMLHTTP fundamentally limits the submission of cross-origin requests.

Browser support: Internet Explorer actually opens two backdoors for this security policy. One is: it assumes that your local file naturally knows what content will be accessed, therefore, no warning will be reported if your local file accesses external data. The other is: when the website script you visit is intended to access cross-domain information, it will only pop up a dialog box to remind you. If a fraudulent website uses this method to provide you with a fake page, and then you can remotely log on to the real banking server through XMLHTTP. One of the 10 users is confused and click OK. Their account theft was successful! Think about how dangerous this is!

FireFox does not. By default, FireFox does not support cross-origin XMLHTTP requests and does not give hackers such an opportunity.

Avoid same-origin policy:

JSON and dynamic script Markup

<Script type = "text/javascript"
Src = "http://yoursiteweb.com/findItinerary? Username = sachiko &
Reservationnum= 1234 & output = json & callback = showItinerary "/>

When the JavaScript code dynamically inserts the <script> flag, the browser accesses the URL in the src attribute. This will send the information in the query string to the server. In listing 1, username and reservation are passed as name-value pairs. In addition, the query string contains the output format of the request to the server and the name of the callback function (showItinerary ). <Script> after the tag is loaded, the callback function is executed and the information returned from the service is passed to the callback function through the callback function parameters.

Ajax proxy

Ajax proxy is an application-level proxy server used to mediate HTTP requests and responses between Web browsers and servers. The Ajax proxy allows the Web browser to bypass the same-origin policy so that XMLHttpRequest can be used to access a third-party server. To implement this bypass, you can choose from the following two methods:
The client Web application knows the third-party URL and passes it as a request parameter in the HTTP request to the Ajax proxy. Then, the proxy forwards the request to [url] www.jb51.net [/url]. Note: You can hide the use of the proxy server in the implementation of the Ajax library used by Web application developers. For Web application developers, it may seem completely different from the same-origin policy.
The client Web application does not know the third-party URL and tries to access resources on the Ajax proxy server through HTTP. With a predefined encoding rule, the Ajax proxy converts the requested URL to the URL of a third-party server and retrieves content on behalf of the customer. In this way, Web application developers seem to be communicating directly with the proxy server.

Greasemonkey

Greasemonkey is a Firefox extension that allows users to dynamically modify the style and content of Web pages. Greasemonkey users can associate user script files with a URL set. When the browser loads the page through the URL set, these scripts are executed. Greasemonkey provides additional permissions for the user script API (compared with the permission for the script running in the browser sandbox ).

GM_XMLHttpRequest is an API in which it is essentially an XMLHttpRequest with no same-origin policy. The user script can replace the built-in XMLHttpRequest browsing with GM_XMLHttpRequest to permit XMLHttpRequest to perform cross-origin access.

The use of GM_XMLHttpRequest can only be protected by means agreed by the user. That is to say, Greasemonkey requires user configuration only when the association between the new user script and the set of specific URLs is established. However, it is hard to imagine that some users may be deceived and accept the installation without fully understanding the consequences.

I hope this article will help you design javascript programs.