1. Home
  2. Web App Vulnerabilities
  3. How to remediate – Mort Bay Jetty Multiple XSS
Searching...

How to remediate – Mort Bay Jetty Multiple XSS

Contents

1. Introduction

Mort Bay Jetty Multiple XSS affects web servers, allowing attackers to inject malicious script code into a user’s browser. This can lead to account takeover, data theft, and website defacement. Systems running vulnerable versions of Mort Bay Jetty are at risk. Impact is likely to be high on confidentiality and integrity, with potential for availability disruption if the injected scripts cause denial of service.

2. Technical Explanation

  • Root cause: Missing input validation in multiple locations within Jetty’s request handling process.
  • Exploit mechanism: An attacker crafts a malicious URL containing JavaScript code and sends it to a vulnerable Jetty instance. When a user visits this URL, the injected script is executed in their browser. For example, an attacker could use a crafted link like http://example.com/?param=
  • Scope: Affected versions of Mort Bay Jetty are not specifically detailed in the provided information but the references point to Jetty 6x and 7x.

3. Detection and Assessment

Confirming a system is vulnerable requires checking the Jetty version and looking for signs of unsanitised input. A quick check involves identifying the Jetty version running on the server.

  • Quick checks: Access the Jetty administration interface (if enabled) or examine HTTP response headers for the Jetty version string.
  • Scanning: Nessus plugin ID 37927 can detect this vulnerability, but results should be verified manually.
  • Logs and evidence: Examine application logs for suspicious characters or patterns in user input fields. Look for instances of HTML tags or JavaScript code being logged without proper encoding.
java -jar jetty-version.jar # Example command to determine Jetty version (requires a separate tool)

4. Solution / Remediation Steps

Currently, there is no known solution detailed in the provided context. However, applying the latest security patches for your specific Jetty version is recommended once available.

4.1 Preparation

  • A change window may be required depending on the size and complexity of the deployment. Approval from a senior IT administrator is recommended.

4.2 Implementation

  1. Step 1: Download the latest security patch for your specific Jetty version from the vendor’s website.
  2. Step 2: Stop the Jetty service using the appropriate command for your operating system (e.g., sudo systemctl stop jetty).
  3. Step 3: Apply the downloaded patch to the Jetty installation directory.
  4. Step 4: Restart the Jetty service using the appropriate command (e.g., sudo systemctl start jetty).

4.3 Config or Code Example

Before

//Example - insecure code snippet (illustrative only)
String userInput = request.getParameter("param");
response.getWriter().println(userInput); //Directly outputting user input without sanitisation

After

//Example - secure code snippet (illustrative only)
String userInput = request.getParameter("param");
String sanitizedInput = sanitizeInput(userInput); //Sanitise the input before outputting
response.getWriter().println(sanitizedInput);

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this type of vulnerability. Input validation is crucial for blocking malicious data, while least privilege limits the impact if an attack succeeds.

  • Practice 1: Least privilege – restrict the permissions of the Jetty process and web applications to minimise potential damage from exploitation.
  • Practice 2: Input validation – implement strict input validation on all user-supplied data to ensure it conforms to expected formats and does not contain malicious characters or code.

4.5 Automation (Optional)

# Example Ansible playbook snippet (illustrative only - requires adaptation)
- name: Apply Jetty security patch
  shell: /path/to/patching_script.sh #Replace with actual patching command
  become: true

5. Verification / Validation

Confirm the fix by rechecking the Jetty version and attempting to exploit the vulnerability again. A smoke test should verify core functionality remains operational.

  • Re-test: Attempt to inject a simple XSS payload (e.g., http://example.com/?param=) and confirm it does not execute in your browser.
  • Smoke test: Verify that core website functionality, such as login and content display, still works as expected.
  • Monitoring: Monitor application logs for any unexpected errors or suspicious activity related to user input processing.
java -jar jetty-version.jar # Post-fix command and expected output (e.g., Jetty 9.4.48.v20220624)

6. Preventive Measures and Monitoring

Regular security baselines, pipeline checks, and a robust patch process can help prevent future vulnerabilities. For example, update your CIS benchmark or GPO/Intune settings to reflect the latest Jetty security recommendations.

  • Baselines: Update security baselines to include recommended Jetty configurations and hardening measures.
  • Asset and patch process: Implement a regular patch review cycle for all critical systems, including Jetty servers, to ensure timely application of security updates.

7. Risks, Side Effects, and Roll Back

  • Risk or side effect 2: Service downtime during patching can impact users. Mitigation involves scheduling patches during off-peak hours and communicating planned downtime.
  • Roll back: 1) Stop the Jetty service. 2) Restore the previous backups of the Jetty configuration and web application files. 3) Restart the Jetty service.

8. References and Resources

Was this article helpful?

Yes No

Related Articles