How to remediate – Apache Tomcat /servlet Mapping XSS

1. Introduction

The Apache Tomcat /servlet Mapping XSS vulnerability is a cross-site scripting issue affecting web servers running Apache Tomcat. This allows an attacker to inject malicious scripts into web pages viewed by other users, potentially stealing cookies, redirecting users, or defacing websites. Systems using Tomcat as their servlet container are usually affected. A successful exploit could lead to loss of confidentiality, integrity and availability of the impacted web application.

2. Technical Explanation

Apache Tomcat is a servlet container used for Java Servlet and JavaServer Pages technologies. The vulnerability occurs because of how Tomcat handles requests using the /servlet/ mapping when invoking various servlets or classes. This can cause Tomcat to throw an exception, which allows attackers to inject malicious scripts through cross-site scripting (XSS).

• Root cause: Tomcat throws exceptions when handling anonymous servlet classes not defined in a web.xml file.
• Exploit mechanism: An attacker crafts a URL that invokes an undefined servlet via the /servlet/ mapping, causing an exception and injecting malicious JavaScript code into the response. For example, visiting http://example.com/servlet/EvilServlet could trigger the vulnerability if EvilServlet is not defined in web.xml.
• Scope: Affected versions of Apache Tomcat are those that allow invocation of anonymous servlets via /servlet/.

3. Detection and Assessment

To confirm a system is vulnerable, check the Tomcat configuration for the unmapped ‘invoker’ servlet. A thorough method involves reviewing the web.xml file for any undefined servlet mappings.

• Quick checks: Check the Tomcat version using tomcat/bin/version.sh or by accessing the Tomcat manager application and viewing the server info page.
• Scanning: Nessus plugin ID 32874 can detect this vulnerability. This is an example only, other scanners may also provide detection capabilities.
• Logs and evidence: Look for exception messages in Tomcat’s catalina.out log file related to servlet initialization or invocation failures.

tomcat/bin/version.sh

4. Solution / Remediation Steps

To fix the issue, unmap the ‘invoker’ servlet from the /servlet/ mapping in Tomcat’s web.xml file. This prevents anonymous servlets from being invoked and mitigates the XSS risk.

4.1 Preparation

• Back up the web.xml file before making any changes. Stop the Tomcat service to ensure configuration changes are applied correctly. A roll back plan involves restoring the original web.xml file and restarting Tomcat.
• There are no dependencies or pre-requisites for this fix, but a change window may be required depending on your organisation’s policies.

4.2 Implementation

1. Step 1: Open the /tomcat-install-dir/conf/web.xml file in a text editor.
2. Step 2: Locate the entry for the ‘invoker’ servlet mapping to /servlet/.
3. Step 3: Comment out or remove the entire and block associated with the invoker servlet.
4. Step 4: Save the changes to the web.xml file.
5. Step 5: Restart the Tomcat service for the changes to take effect.

4.3 Config or Code Example

Before

<servlet>
  <servlet-name>invoker</servlet-name>
  <servlet-class>org.apache.catalina.servlets.InvokerServlet</servlet-class>
  <init-param>
    <param-name>debug</param-name>
    <param-value>0</param-value>
  </init-param>
</servlet>
<servlet-mapping>
  <servlet-name>invoker</servlet-name>
  <url-pattern>/servlet/*</url-pattern>
</servlet-mapping>

After

<!-- <servlet>
  <servlet-name>invoker</servlet-name>
  <servlet-class>org.apache.catalina.servlets.InvokerServlet</servlet-class>
  <init-param>
    <param-name>debug</param-name>
    <param-value>0</param-value>
  </init-param>
</servlet>
<servlet-mapping>
  <servlet-name>invoker</servlet-name>
  <url-pattern>/servlet/*</url-pattern>
</servlet-mapping> -->

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this vulnerability type. Least privilege reduces the impact if exploited, and input validation blocks unsafe data from reaching the application.

• Practice 1: Implement least privilege principles for Tomcat processes and user accounts.
• Practice 2: Enforce strict input validation on all user-supplied data to prevent malicious scripts from being injected.

4.5 Automation (Optional)

# Example Bash script to back up web.xml before modification
#!/bin/bash
TIMESTAMP=$(date +%Y%m%d%H%M%S)
cp /tomcat-install-dir/conf/web.xml /tomcat-install-dir/conf/web.xml.$TIMESTAMP
echo "Backup of web.xml created: /tomcat-install-dir/conf/web.xml.$TIMESTAMP"

5. Verification / Validation

To confirm the fix, check that the ‘invoker’ servlet is no longer mapped in the web.xml file. Re-test by attempting to access an undefined servlet via the /servlet/ mapping.

• Post-fix check: Verify the invoker servlet mappings are commented out or removed from /tomcat-install-dir/conf/web.xml.
• Re-test: Attempt to access a non-existent servlet using http://example.com/servlet/TestServlet. You should receive an error message instead of executing the script.
• Monitoring: Monitor Tomcat’s logs for any exceptions related to servlet initialization or invocation failures.

grep -q "<servlet-mapping> <servlet-name>invoker</servlet-name>" /tomcat-install-dir/conf/web.xml

6. Preventive Measures and Monitoring

Update security baselines to include the requirement for unmapped ‘invoker’ servlet, and add checks in CI/CD pipelines to prevent this issue from reoccurring.

• Baselines: Update your Tomcat security baseline or policy to require that the invoker servlet is disabled.
• Pipelines: Add a static analysis check to your CI/CD pipeline to verify the /servlet/ mapping configuration in web.xml.
• Asset and patch process