Security Advisory: Struts Error Message Cross Site Scripting

Background

Struts is an open source framework for building web applications. The core of the Struts framework is a flexible control layer based on standard technologies such as Java Servlets, JavaBeans, resource bundles, and the Extensible Markup Language (XML). Struts can be used with different Java engines, such as WebLogic, TomCat, JRun, etc.

Scope

After identifying in Struts an error message echoing the path back to the user, Hacktics conducted research to identifyi a cross site scripting vulnerability in the implementation of this error on different application servers.

The Finding

When attempting to access a non existent Struts action URL, the struts infrastructure generates an error echoing the path of the requested action. The mechanism generating this error does not perform sufficient input validation nor perform HTML encoding of the output, thus exposing the system, in some environments, to a Cross Site Scripting attack.

Details

Normal Struts action URLs take the format of:
 
http://foo.bar/strdir/action.do

When accessing a non existing action, while maintaining the do suffix, such as:
 
http://foo.bar/struts-virtdir/NOSUCHACTION.do

The struts request handler processes the request, and generates a 400 Bad Request error.
The body of the default erroneous response includes the following text:
 
Invalid path /NOASUCHACTION was requested

By replacing the non existent action with a script, Cross Site Scripting is possible.

Exploit

The exploit is done by including any script (JavaScript/VBScript) between HTML SCRIPT tags. For instance:
 

Versions Tested

Vulnerable
 
Struts 1.2.7 Running on WebLogic 8.1 SP4
Struts 1.2.7 Running on WebLogic 8.1 SP5
Struts 1.2.7 Running on Resin Web Server

Not Vulnerable
 
Struts Running on Apache Tomcat 5.5.9
Struts Running on Apache Tomcat 5.5.9

Solution

The Apache Struts group has been notified of this vulnerability on November 3rd, and has fixed the problem in the new Struts release (1.2.8). Upgrading to the new version will eliminate the threat. Alternatively, a work around is available on existing versions by configuring the web server to display custom error messages rather than the default ones.

Credit

The vulnerability was discovered on November 3rd, 2005, by Irene Abezgauz, as part of Hacktics' research activities