An XSS attack abuses the trust of a user towards the content retrieved from a website. This malicious content includes HTML elements that allow an attacker to control the execution of client-side (Java)scripts in the trusted security context of the site. In other words, the attacker can sneak script code into a website that executes with the same rights and permissions as script code that was created and delivered by the original application programmers.

For example, when a dynamic web page such as http://example.com/showdetails.jsp?name=Joe+The+Plumber simply prints the value of the 'name' parameter in the content of the HTTP response, an attacker is able to inject a malicious script by constructing a URL such as http://example.com/showdetails.jsp?name=<script>alert(document.cookie)</script>.

Instead of just opening an alert dialog, the attacker can modify the shown page in any way imaginable. A script could, for example, add an additional login form to the page, which the victim will submit to the attackers server, thus allowing identity theft.

Cause

Sites that are vulnerable to this problem typically have difficulties in filtering characters like <, >, quotes, double-quotes and others, which allow attackers to trick the browser into interpreting code. In general, the cause is a lack of proper filtering of user data input, which is then outputted, again unfiltered, to other users.

Exploitability

In order to allow an attacker to take advantage of a victim she needs to trick the user to click on a prepared link she provided (reflected XSS), or manipulate the backend content, like posting a forum entry with malicious content (persistent XSS) which is then served to the victim and executed.

A third type is the DOM-based XSS attack vector, which is very similar to the reflected XSS type but additionally exploits the fact that a victim might store the malicious HTML content in a trusted location, for example, download the page to the local file system. Then, the DOM-based XSS attack script may allow an attacker to trigger executables on the client host or read confidential data in the local security zone.

Impact on Cross Site Request Forgery

An XSS attack can disable your protection against an CSRF attack. The most common protection against CSRF is a per-request token, which is validated with every request in addition to the users session cookie. An attack can use XSS to read the one-time token of a form through injected Javascript on the same page. That token can then be used by the attacker to forge a valid but malicious request.

Possible Remedies

Developers need to to consider filtering of data from user input, and filtering of data that is shown to users. The most common solutions focus on filtering the output of data when it is rendered in an HTML page. This is especially important in dynamic web applications, where content can include any character that is for example retrieved from a database.

Considerations for Seam framework users

In a Seam application, HTML output is typically generated with an XHTML template and through JSF components.

Filtering output with JSF components

The most commonly used JSF component for this purpose is <h:outputText/>. The following example prints the name request parameter value:

<h:outputText value="#{param.name}"/>

The JSF component will filter the output and escape dangerous characters as XHTML entities. For example, the character < is escaped as &lt; automatically. In the JSF source code for this component, you can find the following routine:

switch (c) {
    case '<': htmlEntity = "&lt;"; break;
    case '>': htmlEntity = "&gt;"; break;
    case '&': htmlEntity = "&amp;"; break;
    case '"': htmlEntity = "&quot;"; break;
}

The outputText component also has a switch to disable escaping of dangerous characters. The following example would open your application for an XSS security vulnerability:

<h:outputText value="#{param.name}" escape="false"/>  <!-- DON'T DO THIS! XSS SECURITY HOLE! -->

You should only use the escape=false switch when you are sure that the content you are printing into HTML does not contain any dangerous characters. For example, if your text content is already filtered and stored escaped in the database, you might want to avoid double-escaping of the & symbol:

<h:outputText value="#{myBean.myTextContent}" escape="false"/>  <!-- Content contains &entity; and is already safe! -->

The following XHTML template will implicitly create an <h:outputText/> component and is also safe:

<p>This is my name: #{param.name}</p>

Other built-in JSF components such as <h:outputLink/> and <h:message/> are derived from the same parent component as <h:outputText/> and are therefore also filtering values automatically.

Filtering output with Seam Text

The <s:formattedText value="#{markup}"/> component provided by Seam renders text markup in Seam's own markup syntax. In addition to safe markup, the output parser also accepts a subset of HTML tags. The following example renders some bold text:

<s:formattedText value="<b>Bold Text</b>"/>

To prevent malicious characters and XSS, the formatted text parser will recognize and sanitize any markup. You can find the source code and the allowed HTML elements, attributes, and allowed values in the seam-text.g grammar definition. The sanitization rules have been adapted and expanded from http://wiki.whatwg.org/wiki/Sanitization_rules, so only safe HTML is allowed in markup.

Evaluating third-party component libraries

Any JSF component can potentially render unsafe HTML, or worse, render unfiltered user input parameters. You should monitor the security vulnerabilities of any third-party JSF component library you are using. For example, the Tomahawk components exposed you to a vulnerability that would allow an attacker to sneak malicious content into a request URL parameter.

Further Reading

http://www.owasp.org/index.php/Top_10_2007-A1

http://en.wikipedia.org/wiki/Cross-site_scripting

http://ha.ckers.org/xss.html is a collection of common XSS attacks, illustrates how an attacker may choose between encodings and tags to achieve his goal

http://www.xssed.com/ provides a catalog of real-world exploits

http://cwe.mitre.org/data/definitions/79.html describes the classification of XSS within the Common Weakness Enumeration System of the National Vulnerability Database (NVD)

http://recon.cx/2008/a/alexander_sotirov/recon-08-sotirov.pdf describes how attackers reverse engineer the weaknesses of XSS filters