A lot of software comes bundled with various supporting files. These may include programming examples, help files, and scripts that make installation and configuration easy. These supporting files are supposed to be removed in production environments after the installation and configuration is complete. But many organizations may not have the resources to identify and remove these non-essential example files from their production environments. The actual software may be security hardened, but many times these supporting files contain vulnerabilities.
Apache Struts2 Example App Cross-site Scripting Issue
I came across one such issue recently with the example applications in Apache Struts2. I was developing a QualysGuard vulnerability signature for one of the Struts2 advisories when I noticed different examples that come bundled with the full distribution of Struts. Upon browsing the various sample applications and reviewing the source code of a few pages, I discovered a cross-site scripting vulnerability in one of the pages in the “struts2-showcase” example. Here I will describe how someone with malicious intent could exploit cases like this if the examples are not restricted or removed.
The vulnerability has no remarkable threat impact since these examples are not intended to be deployed in a production environment. However, it is still an issue if the example applications are not removed, making the system vulnerable to execution of script code.
Apache Struts2 is a framework for creating Java web applications. The full distribution package of Struts2 is bundled with example applications like “struts2-showcase”, “struts2-blank”, “struts2-mailreader” and so on and so forth. If these example applications are not removed, “viewSource.action” in “struts2-showcase” example is prone to a cross-site scripting vulnerability that could allow a malicious user to execute arbitrary HTML and script code.
The issue is that input passed via the 'config' and 'className' parameters in '/struts2-showcase/viewSource.action' is not properly sanitized before it is returned to the user. This can be exploited to execute arbitrary HTML and script code in a user’s browser session in the context of a vulnerable site.
Proof of Concept
Upon receiving the sample request (see A), processing on values assigned to "config" and "className" parameters is done in viewSource.java and the input is rendered to the user via viewSource.jsp. The input is not sanitized, resulting in script code execution. For instance, for the sample request, alert boxes are popped up (see B). Below is a snippet of the HTML source code from the resulting output. As you can see below, the <script> tags are not properly escaped, allowing arbitrary script code to be executed in the context of the application.
-------- Snippet of Output from the Sample Request ----------
id="three" label="Java Action"
Exploit Tested On
- Apache Struts2 188.8.131.52
- Apache Struts2 184.108.40.206
- Apache Struts2 220.127.116.11
The issue was reported to the Struts Security Team and has been fixed in Struts Version 2.3.3.
There are quite a few applications which usually get deployed without many restrictions, leaving them vulnerable to being exploited. Caution should be taken to change or disable “defaults” and/or “example applications” so that they don’t become a source for compromise. The bottom line is that deploying example applications bundled with software straight out of the box can be risky, and administrators should be careful during installation. Such example applications should be removed and never used in production environments.