This article can also be found in the Premium Editorial Download "Information Security magazine: Setting up for BYOD success with enterprise mobile management and mobile application security."
Download it now to read this article plus other related content.
As many organizations still struggle to manage security components such as antivirus, firewalls and spam filters, the threat landscape has evolved into a much more sophisticated and dangerous
CROSS-SITE SCRIPTING BASICS
XSS occurs when an application assumes a certain type of input, but instead an unexpected input is received and processed by the application. The malicious input must be structured in a certain way to exploit the interpreter in the browser. This could happen by using various tools and scripting techniques that effectively manage to switch the browser execution context from a data (passive) context to a code (active) context. To demonstrate this, we can consider a simple Web application which, without doing any (proper) filtration, is using the data the end-user submits to a login page and places it directly into the output stream. An attacker notices such behavior and to exploit it, he lures the victim into clicking a maliciously crafted link containing the string “<script>alert(‘document.cookie’)</script>”. When the victim’s browser interprets the Web server response, instead of displaying a welcome message to the end user, it opens a pop-up box displaying all the client cookies belonging to http://xssed. This attack is depicted in Figure 1.
A hacker armed with such information could impersonate the legitimate user and commit fraud in his name. The attack demonstrated above is a simple example; in reality, a malicious user could silently steal the cookie rather than display it to the user. A simple XSS cookie theft exploit can be implemented by changing the previous link to something like the below:
Without going into the technical details, when this string is executed by the victim’s browser it sends all the victim’s browser cookies belonging to http://xssed to an attacker controlled site.
This attack is just the tip of the iceberg. It can be demonstrated that XSS attacks, especially when combined with other attacks, can shake and possibly knock out all three pillars of information security, namely the confidentiality, integrity and availability of resources. They could be impacted through attack patterns that steal and disclose file content, manipulate file content and even bring down a site via denial-of-service (DoS).
XSS ATTACK TYPES
There is no universally accepted classification of XSS flaws but most experts distinguish between two primary classes, namely, non-persistent and persistent. The non-persistent XSS attack class, known as “reflected XSS,” occurs, as in Figure 1, when the vulnerable Web application immediately includes the request to the HTTP response without doing any sanitization. Related to this class is the “Document Object Model (DOM)-based XSS,” the main difference being that the XSS payload does not need be sent or echoed by the website. The persistent class, called “stored XSS," occurs when the Web application accepts malicious code, stores it and later distributes it in response to a separate HTTP request. These attacks can be more serious than the non-persistent ones because the code is injected once but could affect a large number of users.
We expect that in the future two more categories of XSS attacks will surface and become more evident: “distributed XSS” and “combined XSS” attacks. A distributed XSS occurs when an XSS attack payload is injected into one application but reveals its presence in another Web application. This could happen when a website collects and stores data which in turn is used by another website. It can be compared to a stored XSS attack but it is of a distributed nature. A combined XSS arises when an attacker combines or blends together different categories of XSS attacks. For example, this might work by combining “stored XSS” and “DOM-based XSS” into one chain. Thus, it could happen that an XSS attack payload gets injected and stored in a server and when a user visits the XSSed site, his DOM data is manipulated. The diagram below, Figure 2, illustrates current and prospective XSS attack types. The latter are shown in italics.
XSS ATTACK SOURCES
XSS scripting attacks can be introduced at design and implementation time and in theory can arise in any Web-based application type and possibly at any application layer. A company might think it is well-protected against such threats because it has a firewall, SSL and strong security policies, but the reality is that an XSS payload can pass through undetected via any conventional channel, HTTP or not. The major difficulty in protecting against this attack class is that there are so many different and subtle sources, technologies and ways in which such attacks could be crafted, hidden and delivered to a host.
A developer might believe that an XSS attack could be installed only in an HTML form field and possibly in the URL. However, this is incorrect as all the data coming from the Web browser should be considered tainted, meaning that it could be spoofed or modified by a malicious entity. For instance, even the User-Agent HTTP header field, which is used to provide information such as the browser’s name and version, can be manipulated by a malicious application, leading to an XSS attack. One such tool that allows updating the agent field to any string (including an XSS attack vector) is the Firefox plug-in “User Agent Switcher.” Similarly, the browsing software could be hijacked by malware (such as a man-in-the-browser Trojan) and because the request could have passed through a malicious channel before reaching the target Web server (such as a compromised proxy). Unfortunately, this point is often missed by researchers and popular XSS scanning tools.
If the Web application uses some piece of information from the Web browser, then that information is a potential injection point, regardless of whether the value is supplied manually or automatically by the browser. By analyzing the HTTP protocol, HTML features, and the different ways of passing of information to a Web server, we can come up with a table that groups together the different sources that might carry an XSS attack payload to a Web server. The sources of such data are summarized in Table 1.
|Tainted Source||Explanation |
|Uniform Resource Identifier (URI)|| |
Any portion of the URI can be manipulated for XSS.
Also, should the website directly display the URI or a part of it in a page, then that has the potential to be exploited.
HTTP Request Body
The HTTP request body contains, besides other things, data collected from end users (typically by forms). Since there is direct user input involved this source, it immediately qualifies as tainted.
The above applies to all the fields users are expected to populate and to less obvious fields that users are not expected to alter such as hidden fields (input type=hidden) or input fields with the disable attribute. Technically, any form field or any HTTP request body parameter can be easily modified before it is submitted to the server.
|HTTP Request Headers|| |
Every Web browser includes certain HTTP headers with each request. Everything from the Web browser can be spoofed or modified.
Two of the most common headers used to conduct XSS attacks are the Cookie and the Referer header.
Should the website parse and display any of the HTTP client headers, it's potentially vulnerable to XSS unless proper protection is in place.
Table 1. XSS Main Sources
Ultimately, the highlighted sources represent the vast majority of the locations where an XSS payload might get stored during its transit to a target host. However, it is also worth noting again that in reality there may be more subtle methods such as binary content (including images, movies and PDF files), and sources such as FTP, file system or database that can be used to house and deliver an XSS attack payload.
XSS ATTACK TOOLS
The tools and technologies used by information security professionals to test and protect applications are sometimes used by black- and gray-hat hackers to exploit security vulnerabilities in websites. These tools range from man-in-the-middle (MITM) proxy tools such as BURP to full-blown multi-function tools such as WebScarab. In our work, we used WebScarab to evaluate the anti-XSS prototype we developed. Testing with this tool involved modifying the raw HTTP request and injecting various test XSS attack vectors. This process is known as fuzzing and is used to identify potential security holes.
Besides the ease of use and availability of these tools in the public domain, hackers often use non-technical means to trick users into executing XSS exploit code. Typically, they use social engineering techniques such as phishing, pre-texting and interactive voice response (IVR). Back in the 80s and 90s, the famous former hacker Kevin Mitnick used social engineering to manipulate people into disclosing sensitive information, which he then used to bypass existing technical security measures. Aware that some users might get suspicious of their activity, hackers try their best to conceal their activity. Techniques such as encoding, code obfuscation and URI shorteners are often used to hide malicious XSS payloads and bypass various protection filters.
XSS DEFENSE STRATEGIES
The natural and simple way of developing Web applications is prone to XSS as well as other vulnerabilities. Over the years, various tools and techniques have been developed for mitigating XSS. They include client-side tools such as NoScript and Noxes, hybrid tools such as Noncespaces and Secure Web Application Proxy (SWAP) and server-side tools such as ModSecurity and PHPIDS. Analzsing dozens of anti-XSS products and research on malware detection, we identified a set of parameters that can be used to analyze, classify and appreciate the existing work on XSS protection: detection, reaction, location and time. In our work, location is used as the primary classifier to categorize existing anti-XSS solutions.
The detection phase, composed of an analysis method and a detection technique, is used to decide whether an XSS vulnerability exists in a target system. After a vulnerability is confirmed, the reaction phase is triggered to decide the action to follow. The third parameter, time, is the software phase during which input is analyzed. Lastly, the location indicates where the protection mechanism is installed. Table 2 lists the different methods that can be used to implement or satisfy each parameter.
|Time||Development Time |
Table 2. Anti-XSS Tool Composition Parameters
Information-flow techniques and anomaly-based detection can be used to detect previously unknown vulnerabilities but these techniques tend to be prone to a high false positive rate (FPR). This is mainly related to the limitations of the approximation techniques and the training datasets, which cannot possibly be exhaustive in the case of XSS. Signature-based detection is the approach commonly used by firewalls, misuse-based IDS and client-side injection filters; but if used alone this technique can lead to a high false negative rate (FNR). This is because it fails to detect uncommon XSS attack vectors, such as obfuscated vectors, unless there is a signature for each possible attack. This is in contrast to the grammar-based technique, which is usually the most accurate. Nevertheless, this approach requires each application entry point to be defined a priori. Turning to the analysis methods, we have identified secure coding as the only approach that can be used for prevention, detection and reaction across the whole software life cycle. However, the downside of this approach is that it requires Web developers to be well-trained and disciplined to write or use secure libraries.
XSS vulnerability detectors can be deployed either on the server, client or in a hybrid model.. The client-based solutions, such as Microsoft Internet Explorer 8 built-in XSS filter or Firefox add-on NoScript, give end-users more protection against websites that do not have good security processes in place. However, they suffer from various weaknesses. The main drawback is the necessity to install updates or additional components on each user's workstation. Such a requirement can be perceived as an obstacle or might not even be considered by the vast majority of users. In fact, there are users, mostly people in the Republic of China, who are still using IE6, which came out in 2001. Client-based solutions are prone to zero-day attacks and most of the approaches in this class, because of their generic nature, lead to either too many false positives or too many false negatives. The server-based approach is the preferred alternative for an enterprise owing to its practicality, reliability and because it offers the most immediate protection.
A NEW XSS DEFENSE FRAMEWORK
Irrespective of the approach, current defense strategies are all affected to different extents by false positives and false negatives, and are subject to varying ratios of ease of use and implementation. Having a server-based solution seems to be ideal for an enterprise because it overcomes, or reduces to a great extent, the disadvantages of client-side tools. However, the evaluated technologies in this category demonstrate various limitations when it comes to addressing the requirement for ease of use and accuracy. A quick schematic comparison of the current anti-XSS solutions is shown in the set diagram of Figure 3. The items in italics represent examples of popular cross-site scripting defense tools.
Returning to the server-side tools, we find that some require the developers to update multiple entry/exit points, each point typically being a Web page, module or function. For instance, to use Microsoft's Anti-Cross Site Scripting Library developers are explicitly required to identify the application entry/exit points and then to modify the Web code to call the safe encoding functions. Side effects of this distributed, almost ad-hoc, approach to security are implementation inconsistencies, extra development effort and increase in future maintenance costs. Some of these server-side tools also feature a boilerplate reaction phase, meaning they only support a system-defined reaction, typically consisting of blocking and/or logging the malicious request. This is usually the case with firewall systems. This type of one-fits-all approach to security protection makes such tools ineffective towards protecting the atypical organization.
Server-side tools also can have high FPR values. Fundamentally, this problem is related to the analysis method and detection techniques adopted by the protection tool. Most popular products, such as ModSecurity and PHPIDS, adopt a blacklist approach to XSS attacks. This approach is very effective when all the combinations are known in advance but when used as the primary (and sometimes only) defence mechanism, is weak for protecting against the plethora of every growing XSS attack patterns.
To address these limitations, we came up with a framework that is based on a secure-coding analysis method and a hybrid security model built primarily on a grammar-based technique. When implemented, this framework serves as a thin layer between the Web application and the user-generated input. This layer is driven by a knowledge-base that externalizes the organization’s anti-XSS policy. Making up the knowledge base is a rule repository allowing developers to specify how to react to malicious input. The high-level architecture of the anti-XSS framework is shown in Figure 4.
The framework rule language is expressive enough to allow, for instance, the blocking of the attack described in Figure 1 with great ease. One way of doing this could be by defining a specific rule: When the name parameter is passed to the server, it should be accepted as legitimate input only if it is made up of letters and possibly the apostrophe and hyphen characters. More sophisticated rules can be created by chaining together different actions. As an example, we can have a primary rule that encodes anything that does not have a specific rule bound to it and a secondary rule that rescans the resulting output against a blacklist. The blacklist could, for instance, block suspicious words such as script, apple and object from being processed by the target application. The framework is also secure-by-default and it supports the scanning of the input against any XSS source we identified previously in Table 1.
The anti-XSS framework has been instantiated with success using Java, aspect oriented programming (AOP) and open-source Java technologies such as Enterprise Security API. Using a model consisting of simply one rule that allows only data containing alpha-numeric characters to pass through and encodes everything else, we have managed to successfully block “RSnake's” XSS Cheat Sheet attacks and the like. The end result is a portable component deployable across any Java Enterprise Edition (JEE) application servers and servlet containers. Without requiring any code modifications and recompilations, this out-of-the-box component provides immediate protection to any Java Server Page (JSP) page with accuracy and performance, and without adversely affecting the functioning of the application.
This framework is based on the techniques of validation and context-sensitive encoding, both of which we have demonstrated to be effective in mitigating XSS attacks.
About the authors:
Joseph Bugeja is a software team leader with over 10 years of software development experience. His qualifications and skills have enabled him to take on key roles, from consulting to implementing high-performance multinational applications. He is also responsible for ensuring that company products are compliant with the latest PCI standards. Geraint Price, PhD, is a lecturer in information security at Royal Holloway. His research interests include secure protocols, public key infrastructures, denial-of-service attacks and resilient security. Send comments on this article to firstname.lastname@example.org
This was first published in September 2012