This page has been robot translated, sorry for typos if any. Original content here.

Cross Domain Scripting

Introduction

The idea to write this article occurred to me after it was necessary to give one newcomer a link to a detailed and understandable explanation of this term. Climbing on search engines, I was surprised to find that finding such an article is quite difficult. The term is either not explained at all, or in two words and in English :) . Meanwhile, in Windows, this type of vulnerability is found quite often and they are more than serious! Therefore, in this article I tried to describe this type of attacks, specific features of exploiting this type of vulnerabilities and protecting against them, to give specific examples as thoroughly and clearly as possible. The article was written mainly, of course, for beginners, but, I hope, it will be something useful for more experienced readers.

What is Cross Domain Scripting?

Initially, Cross-Domain Scripting (CDS) was associated with flaws in the security model of the well-known “donkey” aka Internet Explorer (IE). However, since Since the architectural features of modern browsers are not very different from each other, almost all known web browsers are currently subject to attacks of this type. Nevertheless, the existing differences between programs of this class lead to the fact that most often found CDS is “browser-dependent”, that is, for example, it works on IE, but does not work on Opera or vice versa.
Vulnerabilities like CDS are based on the notion of “domain”. In this context, the meaning of this concept is somewhat different from the generally accepted. A “domain” is no longer just a site address on the Internet, and not even “an area of ​​the hierarchical namespace of the Internet” - this concept means a certain “security boundary” (security boundary) that no user script is allowed to go beyond.
The security model of any web browser is based on the principle that resources of different domains (pages, scripts, etc.) cannot intersect in any way with each other, i.e. get access to internal content and data of each other. If it were possible, then, for example, a script on the home page of the young hacker Vasya could get access to the mailbox data on Mail.Ru of an unsuspecting user whom Vasya lured to his page. That would be fun :) ! Moreover, according to the architecture of Windows and the concept of building modern browsers, any network resource on the local network and the client’s own file system are also “domains”, which means that they can be accessed from scripts just like any other resource on the Internet! Actually, it is the local client file system that is most often the target of cross-domain attacks.
At the same time, the interaction between the resources (pages and scripts) within the domain (and all its subdomains!) Between the Microsoft security concept is allowed and in principle not limited. It is difficult to judge whether it is correct or not, but what is easier :) and while expanding the possibilities of web surfing, that’s for sure.
So what is Cross-Domain Scripting? In the context of the foregoing, this term can be translated as - “cross domain scripting”, i.e. “Script crossing domain boundaries” is a violation of that treasured security line, going beyond which gives access to data from other domains, including the client’s local file system. Such a violation is most often accompanied by the ability to record and execute arbitrary HTML and Java code in the context of other domains, read data from other domains (for example, forms with passwords or files on the client system) and even execute arbitrary commands on a remote computer.
Often the concept of "cross-domain scripting" is replaced by the concept of "cross site scripting" (XSS). Indeed, it often happens that the external manifestations of these vulnerabilities are very similar, especially when the result of CDS is the insertion of Java code into the context of another domain. However, despite the similarities, the essence of these vulnerabilities is different:
First, the scope of XSS is by definition limited to one domain. While CDS is generally subject to all domains + local client file system.
Secondly, the cause of XSS vulnerabilities lies in the errors of the scripts located on the server, and, as a rule, lies in the inadequate filtering of data received from the user. The source of CDS vulnerabilities is client software (browser and operating system), and it usually has nothing to do with user data.
Well, we must not forget that the danger level from successful operation by an XSS attacker is much lower than from CDS. Indeed, in the first case, as a maximum, confidential user data (passwords, etc.) will leak, and only from one site, while confidential data may be stolen from any sites, and often execution of arbitrary commands on the client’s system, which allows you to take full control over it.

How it works?

So why does this type of attack become possible? The reason is that the very “security line” between domains is created artificially, that all the work on preventing cross-domain scripting is done by the web browser and its components - there are no architectural restrictions. So, there is always the likelihood of an error in the verification procedures, the possibility of circumventing them, which is being done successfully now.
For more than a decade of history of using web browsers, many ways have been found to overcome the cherished domain boundary. However, most of them can be divided into two classes:
1.Operating security errors in the object-oriented browser model;
2. Using an intermediate link to execute an attack.
Let us consider these classes of attacks in more detail.
The first is based on a pronounced object-oriented architecture of modern browsers and a Java virtual machine. Indeed, all that we see on the web browser screen are objects of certain classes with their properties, events and methods. Using this object-oriented model and Java scripts, we can access any element of the page loaded in the browser, read and write data into it, open new windows, etc. Moreover, using scripts it is possible to partially control the elements of the web browser itself and even user actions: moving “Forward” / “Back” through pages, adding to “Favorites”, etc.
However, individual windows or page elements in a web browser may belong to different domains, which means that it is necessary to stop access to them. We can not allow the user script, opening another domain in a new browser window, had the opportunity to write something there or read from there. We can not allow the script on the page with the frame where the resource from another domain is loaded, to be able to access this frame and get access to its data. Moreover, data leakage from one domain to another is possible not only through properties, but also through methods and events of objects! Let's say the script on the page of the young hacker Vasya, where he lured the unsuspecting user, should not “know” what keys he presses when he enters the password to access Mail.Ru, opened in another browser window. Well, there are a lot of such examples!
Unfortunately, and perhaps fortunately;), such security checks are often performed incorrectly, and sometimes they are completely absent! Therefore, it becomes possible to access page elements from other domains, read data from them, write your Java code into the context of other domains, etc. Because of the rather complex architecture of the object-oriented model, such “holes” in it are found quite often. Below is an example of this class of attacks (Example 1).
To perform attacks of the second class, some intermediate link is used. What to do when direct access to another domain is prohibited? Right! Go around! But what if there is someone go something to whom this appeal is not prohibited, and it will be able to read data from there and transfer to us, or vice versa - write our data into the context of another domain. The most vulnerable from this point of view is Microsoft’s ActiveX technology. ActiveX technology makes available to the user objects, their properties and methods that are used by the operating system for any auxiliary purposes. For example, HTML Help ActiveX component is used to view Windows help files (* .chm) through a web browser. Isn't it convenient? However, ActiveX objects often act as a kind of Trojan horse! The fact is that there is a way to manage these components (download, access their properties and methods) through a web page. To do this, use the tag. But often these ActiveX objects contain methods for manipulating the file system, launching applications, navigating web pages, etc. So there is an opportunity from the outside to perform all these actions and moreover to carry out a full exchange of data with the victim! For example, read the contents of the local client files and send this data back to the script, or use an ActiveX object to open another domain and write its Java code to its context. It is through this class of attacks that sometimes it is possible to achieve the execution of arbitrary code (running cmd.exe with the necessary parameters) on the client’s system. Currently, this type of CDS is also widespread and constantly find new vulnerable ActiveX objects. The following is an example of such a vulnerability (Example 2).
In addition to the considered CDS classes, there are other ways to bypass cross-domain restrictions. True, often these methods are very exotic and occur infrequently. For example, the Cross-Cookie vulnerability discovered in July 2004 (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). It allowed, under certain conditions, to gain access (read / write) to cookies from other domains. And it was one of the few cases when many browsers were vulnerable: IE, Mozilla, Opera, Konqueror.
So CDS is currently a very common type of attack and new ways to exploit these vulnerabilities (“attack vector”) are constantly being discovered.

CDS Examples

To make everything described above clearer - consider a couple of examples of real CDS vulnerabilities. All of them were found in Internet Explorer and allow you to insert your Java code into the context of other domains. This is usually used to steal cookies or perform arbitrary actions during the current user session.

Example 1. Similar Method Name Redirection Cross Domain Vulnerability - CAN-2004-0727 (MS04-038)

This vulnerability was discovered in July 2004 and is related to a security bug in the object-oriented model of IE (1st class CDS vulnerabilities discussed above).
Its essence is as follows. As you know, to load another page into the current browser window (perhaps from another domain), you can use the location.href property or the location.assign () method. However, after loading the required page, further execution of the Java code of the current script is impossible - otherwise the script could load Mail.Ru and perform arbitrary actions in the context of this domain. However, it was possible to circumvent this restriction by redirecting (redirecting) the location.assign () method to the exact same but different window (after all, we have an object-oriented model and we can assign the methods of different objects to each other). As a result, it became possible to execute Java code in the context of the current window, but after loading the required page - as required! The following script performs the required actions:


w = window.open ("javascript: setInterval (function () {try {x = opener.location.href;} catch (e) {location.assign ('jvascript: alert (document.cookie)'); window.close ();}},100)");
w.location.assign = location.assign;
location.href = "/ click? http: // localhost";


First, a new window opens, which is waiting for the page to be loaded (in our case from localhost) into the main (current) window. Meanwhile, the script reassigns the location.assign () methods and starts loading the required page into the main window (localhost). As soon as the download finishes, a trigger is triggered in the loop of the new window, the Java code is inserted by the assign () method (due to the reassignment of the methods, the insertion takes place in the context of the main window) and the new window is immediately closed. As a result of executing the script in the context of localhost, document.cookie is executed.
Apparently, the Microsoft developers did not foresee the possibility of redirecting functions and did not insert a security check (or inserted incorrectly) into this event. To exploit this vulnerability, it is necessary that Active scripting be enabled in the browser. You can read more about this vulnerability and find a working example of an exploit here: http://greyhatsecurity.org/similarmethodnameredir-discussion.htm.

Example 2. DHTML Editing Component ActiveX Control Cross Domain Vulnerability CAN-2004-1319 (MS05-013)

This vulnerability was discovered at the end of last year, but fixed only in February. It refers to the 2nd type of CDS attacks from those considered above, i.e. uses an intermediate (DHTML ActiveX) to conduct an attack. To successfully exploit a vulnerability, you must perform the following sequence of actions:
1.Download DHTML ActiveX. This is done using a tag.




2. Load the object we need in ActiveX object (arbitrary domain). This is done by running our script in the context of DHTML ActiveX.

exploit.DOM.Sсript.execScript ("window.name =" new "; open (" http: // localhost "," new ");");

3. Well, after that you can already insert our HTML and Java code. It will be executed in the context of the loaded domain. Everything is simple to ugliness :) !

exploit.DOM.S Script.exec Script ("alert (document.cookie)");

What are the causes of this vulnerability? I would single out two of them:
First of all, the ability to execute arbitrary scripts from inside the ActiveX object from the outside - in my opinion, this is too much liberty!
Secondly, when a page is loaded into DHTML ActiveX, EVERYTHING is loaded there - even cookies! Question: why? This ActiveX object can be used to edit pages and why cookies are needed there - it’s not clear ...
Naturally, to exploit this vulnerability, it is necessary for the browser to allow ActiveX execution. You can read more about this vulnerability and find a working example of an exploit here: http://greyhatsecurity.org/abusiveparent-discussion.htm.

How to protect yourself?

Protection from cross-domain scripting is not so easy. Since the exploitation options (“attack vector”) of these vulnerabilities are very diverse, most of the measures will be very limited and temporary. It is almost impossible to override all the “attack vectors”. Therefore, I will give a few recommendations that can only reduce the risk of a successful attack, but not fully protect.
1. Observance of care at web surfing.
For the successful completion of almost all varieties of CDS, you must first lure the unsuspecting user to the exploit page, after which he will undergo this attack. You can not trust the links, as if by chance, to throw in the conversation, the various "home pages", etc. This is probably the main recommendation of all. Unfortunately, well-applied XSS can eliminate all caution.
2. Operational installation of patches for the operating system and browser.
Usually for all vulnerabilities published on the Internet manufacturer (even Microsoft :) ) in a short time releases a correction (patch). It will protect against this particular vulnerability, but not from others that have not yet been foundJ (or found, but not given publicity). Naturally, the vulnerabilities discussed in the examples have been fixed by Microsoft for a long time, and whoever wants it, has already taken care of its security.
3. Turn off ActiveX and Active Scripting in the browser.
This measure will make it impossible to run in the ActiveX browser and execute Java or VBS scripts. This will actually make most CDS attacks ineffective, although it can significantly affect the functionality of the sites visited. However, CDS doesn’t always require support from ActiveX or Active Scripting browser for a successful attack - and this is not a panacea for all ills!
4. Work on the Internet only with limited rights.
The implementation of this recommendation will allow, even in the case of a successful attack, to reduce the possible damage from it. As you know, the browser (and hence all the scripts in it) is launched with the rights of the current user. Do not let the hacker Vasya get cmd.exe with administrator rights :) !
Following all these recommendations will help to become hard to reach for Cross-Domain Scripting!