java-jsf-viewstate-deserialization

name	java-jsf-viewstate-deserialization
description	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.

Java 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:

1. The ViewState is serialized on the server and sent to the client
2. The client sends it back on subsequent requests
3. The server deserializes it without proper validation
4. 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 .faces or .xhtml extensions
• You see javax.faces.ViewState in HTML forms
• 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
stateSaver="server"	Low	ViewState stored server-side
stateSaver="client"	High	ViewState sent to client
secretKey missing/weak	Critical	Easy to forge ViewState
secretKey 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

1. ViewState must be client-side (stateSaver="client")
2. Secret key must be weak or known
3. 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

1. Use server-side state saving:

   <context-param>
       <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
       <param-value>server</param-value>
   </context-param>
   

2. 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>
   

3. Update JSF framework to latest version

4. Implement CSRF protection

5. 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:

1. Extract ViewState
2. Use default secret key or try common values
3. Generate payload with ysoserial
4. Inject and submit

Scenario 2: Weak Secret Key

Symptoms:

• Secret key is short or predictable
• Key found in source code or configuration

Exploitation:

1. Use discovered secret key
2. Forge ViewState with malicious payload
3. Submit to trigger deserialization

Scenario 3: ViewState in URL

Symptoms:

• ViewState parameter in URL query string
• Application uses GET requests with ViewState

Exploitation:

1. Extract ViewState from URL
2. Modify and resend request
3. 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:

1. Document findings with evidence
2. Verify exploitability in a controlled manner
3. Assess impact of successful exploitation
4. Recommend mitigations to the application owner
5. Retest after fixes are applied