Use the revised OWASP Top Ten to secure your Web applications -- Part 2

by Tom Olzak | Mar 05, 2007 4:40:00 PM

Tags: SECURITY, XML, Web application, Tom Olzak, XSS, vulnerability, Document Object Model, attacker

Takeaway: Cross-site scripting is the most common Web application vulnerability. Scripts exploiting this weakness can cause serious problems for home and business users. In this article, Tom Olzak explores the types of cross site scripting vulnerabilities, personal or business impact resulting from their exploitation, and ways to eliminate or defend against them.

This article is also available as a TechRepublic download.

In this second installment in a series on the 2007 OWASP Top Ten vulnerabilities, we'll look at the clear leader in the Web application vulnerability space -- cross-site scripting (XSS). XSS vulnerabilities have been around for some time. However, the business risk associated with XSS exploits is rising as the number of worms and viruses targeting this vulnerability increases.

What is XSS?

XSS vulnerabilities are normally found in Web applications in which code injection is allowed. Scripts exploiting this weakness might come from a server, but they are not executed there; they are executed on the client workstation. There are three basic types of XSS vulnerabilities: reflected, stored, and DOM (document object model) based.

Reflected vulnerabilities are the most common. This type of vulnerability is probably present when a user can enter syntactic content into a text field that is then echoed back to the user's display. A search page is one example. When an attacker locates a page with this vulnerability, he simply enters script into the field. When the page redisplays the entered text, the script executes.

In most cases, social engineering would have to be used to get a user to follow a specially crafted URL to launch an attack. Doing so could result in the insertion of the attacker's script in the page (Jeremiah Grossman, "Cross-site Scripting Worms and Viruses," April 2006).

Stored vulnerabilities are just what the name implies. An attacker submits code to exploit an XSS weakness to a Web site, or a portion of a Web site, frequented by other users. Examples include social networking sites and reader comments about posted content. When the victim's browser opens the infected page, the script automatically executes without any user intervention. This is because stored malicious scripts are seen by the browser as coming from a trusted site/server.

The following is a very simple example of a stored script attack.

Script might be inserted into a form field that eventually finds its way to a forum or other service used by a large number of users. For example, an attacker might enter the following when posting to an online forum:

<script>alert('Hello World')</script>

When an unsuspecting user opens the forum post, this script will run on the user's workstation. The result is a harmless text display, but what if the script included code to:

• Display a permissions error message
• Prompt the user for his password
• E-mail the entered password to the attacker's server

The final type of XSS weakness is the DOM based vulnerability. Part of AJAX, DOM is an:

"...interface that allows a programmer to access and manipulate the contents of a Web page or document. It provides a structured object-oriented representation of the individual elements and content in a page with methods for retrieving and setting the properties of those objects" (Mike Hall, "Introduction to the Document Object Model," 2007).

The vulnerability exists in the client-side script. It is typically found where a script module accesses a URL request parameter. If the script uses the parameter information -- without encoding or filtering -- to write HTML to the page in which it runs, there's a good chance a XSS vulnerability exists. Examples and additional information about DOM vulnerabilities can be found in Amit Klein's "DOM Based Cross Site Scripting or XSS of the Third Kind," 2005.

DOM based XSS exploits are difficult to defend against. Because all methods within a DOM page hierarchy are trusted, malicious code inserted into a called parameter will execute at the same security level as non-malicious scripts. Like stored XSS exploits, malicious DOM script defense consists of programmer attention to secure coding techniques.

Business impact

According to Grossman, there are a number of actions that an attacker can perform once she successfully exploits an XSS vulnerability, including:

• Force the sending of e-mail messages
• Transfer money
• Delete or modify data
• Use the victim's workstation to hack other Web sites
• Download illegal content

Essentially, any function that can be performed by a Web page script can be executed by a successful attacker without user intervention.

Preventing XSS vulnerabilities

As with many Web application vulnerabilities, the best defense against XSS exploits is to validate input. For example, ensure angle brackets are not allowed in any input to any Web page fields. This might seem like a very simple approach, but it appears to be one of the best defenses against XSS attacks. According to McClure, Scambray, and Kurtz,

"...nearly ever[y] single XSS vulnerability we've come across involved failure to strip angle brackets from input or failure to encode such brackets in output" (Hacking Exposed, p. 565).

It isn't just angle brackets. No syntactic input should be allowed. Syntactic input can come from databases, other servers, etc. ALL input into a Web application must be filtered to ensure the delivery of clean content to your user population.

Other steps organizations can take to prevent problems caused by XSS vulnerabilities include:

1. Train users to use caution when clicking on links in e-mail messages or in instant messaging.
2. Implement an Internet access control solution to both restrict access to high risk sites (e.g., pornography and pirated media sites) and to prevent access to known malicious sites.
3. Ensure that a personal firewall and up-to-date antivirus software is running on each workstation. Configure the firewall to restrict outbound connections.
4. All sensitive functionality should be protected from bot automation and execution by third-party sites (Grossman).
5. Perform manual or automated code scanning to identify and eliminate potential XSS opportunities.

The final word

XSS vulnerabilities can introduce significant risk into enterprise networks. Sensitive information can be extracted from organizations without the knowledge of users. As the steps listed above show, XSS defense requires user and programmer vigilance as well as technical solutions to protect against human error.