Cross domain scriptingIntroduction
The idea to write this article occurred to me after I needed to give a newbie a link to a detailed and understandable explanation of this term. Climbing the search engines, I was surprised to find that finding such an article is not easy. The term is either not explained at all, or in a nutshell in English . Meanwhile, in Windows, vulnerabilities of this type are detected quite often and they are more than serious! Therefore, in this article I tried to describe this type of attack, the features of exploitation of this type of vulnerability and protection against them, in as much as possible and more understandable way, to give specific examples. 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 the programs of this class lead to the fact that most often the 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 concept of a “domain”. In this context, the meaning of this concept is somewhat different from the generally accepted one. A “domain” is no longer just a website address on the Internet, and not even an “area of the hierarchical namespace of the Internet”, this concept refers to a certain “security boundary”, beyond which no user script is allowed to go.
The security model of any web browser is based on the principle that resources of different domains (pages, scripts, etc.) cannot in any way intersect with each other, i.e. Access each other’s internal content and data. If it were possible, then, for example, a script on the home page of the young hacker Vasya could gain access to the mailbox data on Mail.Ru of an unsuspecting user whom Vasya had lured to his page. That would be fun ! Moreover, according to the Windows architecture and the concepts 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 in the same way as any resource on the Internet! Actually, it is the local file system of the client that is most often the target of cross-domain attacks.
At the same time, the interaction between resources (pages and scripts) within the domain (and all its subdomains!) By the Microsoft security concept is allowed and, in principle, is not limited in any way. It’s hard to judge whether it’s right or wrong, but what’s easier 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. “Crossing the boundaries of the domain with a script” - violation of that coveted 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 write 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 CDS inserts 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 susceptible to all domains + the local client file system.
Secondly, the reason for XSS vulnerabilities lies in the errors of scripts located on the server, and, as a rule, lies in insufficient 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, do not forget that the danger level from the successful operation of 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, and with CDS it is possible to steal confidential data from any sites, and often execute arbitrary commands on the client’s system, which allows you to take complete control over her.
How it works?
So why does this type of attack become possible? The reason is that the very “security line” between the domains is created artificially, that all the work to prevent cross-domain scripting is performed by the web browser and its components - there are no architectural restrictions. This means that there is always the probability of errors in the verification procedures, the ability to get around them, which is currently being successfully done.
Over the ten-year 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. Operation of security errors in an object-oriented browser model;
2.Using an intermediate link to carry out an attack.
Let's consider these attack classes in more detail.
The first is based on a pronounced object-oriented architecture of modern browsers and the Java virtual machine. Indeed, all that we see on the screen of a web browser is 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 into the browser, read and write data to it, open new windows, etc. Moreover, with the help of scripts, it is possible to partially control 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 can belong to different domains, which means that you need to stop access to them. It is impossible to allow a user script to open another domain in a new browser window and be able to write something there or read from there. It is impossible to allow the script on the page with the frame where the resource is loaded from another domain to be able to access this frame and gain 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 an unsuspecting user, should not “know” which keys he presses when he enters the password for entering Mail.Ru, opened in another browser window. Well, there are a lot of such examples!
Unfortunately, and maybe fortunately;), such security checks are often performed incorrectly, and sometimes even completely! Therefore, it becomes possible to access page elements from other domains, read data from them, write your Java code in the context of other domains, etc. Due to the rather complex architecture of the object-oriented model, such “holes” are often found in it. The following is an example of this class of attacks (Example 1).
To perform second-class attacks, some intermediate link is used. What to do when direct access to another domain is prohibited? Right! Go around! And suddenly there is someone go something to whom this appeal is not forbidden, and it can read the data from there and pass it to us, or vice versa - write our data in the context of another domain. The most vulnerable from this point of view is ActiveX technology from Microsoft. ActiveX technology provides the user with objects, their properties and methods that are used by the operating system for any auxiliary purposes. For example, to view the Windows Help files (* .chm) through a web browser, the HTML Help ActiveX component is used. Isn't that convenient? However, often ActiveX objects act as a kind of Trojan horses! 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 of manipulating the file system, launching applications, navigating web pages, etc. T.O. it becomes possible to carry out all these actions from the outside and, moreover, to carry out a complete data exchange with the victim! For example, read the contents of local client files and send this data back to the script, or use an ActiveX object to open another domain and write your Java code in its context. It is with the help of 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 system. Currently, this type of CDS is also widespread and is constantly finding 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 circumvent cross-domain restrictions. True, often these methods are very exotic and are not common. For example, a Cross-Cookie vulnerability discovered in July 2004 (http://www.westpoint.ltd.uk/advisories/wp-04-0001.txt). Under certain conditions, it allowed access (read / write) to cookies of other domains. And this was one of the few cases when many browsers were vulnerable: IE, Mozilla, Opera, Konqueror.
T.O. CDS is currently a very common type of attack, and new ways to exploit these vulnerabilities (“attack vectors”) are constantly being discovered.
To make everything described above understandable, consider a couple of examples of real CDS vulnerabilities. All of them were found in Internet Explorer and allow you to embed your Java code in the context of other domains. This is usually used to steal cookies or perform arbitrary actions within 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 associated with a security error in the object-oriented model of IE (the first class of CDS vulnerabilities from the ones discussed above).
Its essence is as follows. As you know, to load another page into the current browser window (possibly 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 limitation 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 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 - which was required! The following script performs the required actions:
w.location.assign = location.assign;
location.href = "/ click? http: // localhost";
First, a new window opens, which in a loop waits for the page to load (in our case with localhost) into the main (current) window. In the meantime, the script reassigns the location.assign () methods and starts loading into the main window of the required page (localhost). As soon as the download is completed, the trigger fires in the cycle of the new window, the Java code is inserted using the assign () method (due to the reassignment of the methods, the insert occurs in the context of the main window) and the new window closes immediately. As a result of executing the script in the localhost context, document.cookie is executed.
Apparently, the Microsoft developers did not provide the possibility of a redirect of functions and did not insert a security check (or incorrectly inserted) into this event. To exploit this vulnerability, Active Scripting must be enabled in the browser. You can read more about this vulnerability and find a working exploit example 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 was fixed only in February. It belongs to the 2nd type of CDS attacks from those considered above, i.e. uses an intermediate link (DHTML ActiveX) to conduct an attack. To successfully exploit the vulnerability, you must perform the following sequence of actions:
1.Download DHTML ActiveX. This is done using the tag.
2.Download the desired page to us in the ActiveX object (arbitrary domain). This is done by executing our script in the DHTML ActiveX context.
exploit.DOM.Sсript.execSсript ("window.name =" new "; open (" http: // localhost "," new ");");
3. Well, after that you can already embed our HTML and Java code. It will run in the context of the loaded domain. Everything is simple to disgrace !
exploit.DOM.Sсript.execSсript ("alert (document.cookie)");
What are the causes of this vulnerability? I would single out two of them:
Firstly, the ability to execute arbitrary scripts inside an ActiveX object from the outside - in my opinion, this is too much liberty!
Secondly, when loading a page in 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 is not clear ...
Naturally, to exploit this vulnerability, it is necessary for ActiveX to be allowed in the browser. You can read more about this vulnerability and find a working exploit example here: http://greyhatsecurity.org/abusiveparent-discussion.htm.
How to protect yourself?
Protecting yourself from cross-domain scripting is not easy. Because the exploitation options (“attack vectors”) of these vulnerabilities are very diverse, most measures will be very limited and temporary. Overlapping all “attack vectors” is almost impossible. Therefore, I will give some recommendations that can only reduce the risk of a successful attack, but not fully protect.
1. Use caution when surfing the web.
To successfully execute almost all varieties of CDS, you must first lure an unsuspecting user into an exploit page, after which he will be subjected to this attack. You can not trust links, as if by chance, tossed in a conversation, various "home pages", etc. This is probably the main recommendation of all. Unfortunately, well-applied XSS can cross out all caution.
2. Prompt installation of patches for the operating system and browser.
Usually, for all vulnerabilities published on the Internet, the manufacturer (even Microsoft ) issues a patch (patch) in a short time. It will protect against this particular vulnerability, but not from others not yet foundJ (or those found but not made public). 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 their security.
3. Disabling in the ActiveX browser and Active Scripting.
This measure will make it impossible to run in the ActiveX browser and execute Java or VBS scripts. This will really make most CDS attacks ineffective, though it can significantly affect the functionality of the sites you visit. However, CDS does not always require ActiveX or Active Scripting browser support for a successful attack - and this is not a panacea for all ills!
4.Working on the Internet only with limited rights.
The implementation of this recommendation will allow, even in the event of a successful attack, to reduce the possible damage from it. As you know, the browser (and therefore all 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 of these guidelines will help you become vulnerable to Cross-Domain Scripting!