congdong007

Penetration Test、Software Developer

0%

GWT RPC Testing

Posted on In

GWT RPC testing is fundamentally about Java object deserialization boundaries, business logic manipulation, and type system abuse.

Unlike REST APIs, its attack surface is concentrated in:

  • Strongly typed (non-JSON) parameters
  • Java deserialization behavior
  • SerializationPolicy (type allowlist mechanism)
  • Excessive RPC interface exposure
  • Authorization enforced only at the Service layer

Below is a structured breakdown from an offensive security standpoint.

1. GWT RPC Architecture Overview

GWT RPC is the remote invocation mechanism used by Google Web Toolkit.

A typical request looks like:

1
2
3
4
POST /project/module/serviceName HTTP/1.1
Content-Type: text/x-gwt-rpc; charset=UTF-8
X-GWT-Permutation: ...
X-GWT-Module-Base: ...

The payload format resembles:

1
7|0|8|http://target.com/project/|XXXXXXXXXXXX|com.example.client.Service|methodName|java.lang.String/2004016611|test|1|2|3|4|

Core structure:

1
version | flags | stringTableSize | baseURL | strongName | serviceInterface | method | paramTypes | paramValues | ...

2. Overall Testing Methodology

In practice, I approach GWT RPC testing in five phases:

  1. Interface discovery
  2. SerializationPolicy analysis
  3. Parameter tampering
  4. Type confusion testing
  5. Deserialization chain testing

3. Interface Discovery (Reconnaissance)

1) JavaScript reverse engineering

GWT generates *.cache.js files. Search within them for:

1
2
3
ServiceProxy
RemoteService
createProxy

You can usually identify interfaces such as:

1
com.example.client.UserService

2) Traffic interception

Capture a legitimate request and record:

  • strongName
  • module base
  • Fully qualified service name

3) Path enumeration

Common GWT RPC pattern:

1
/module/service

Run directory enumeration to identify exposed endpoints.

4. SerializationPolicy Analysis

Each GWT RPC endpoint relies on a:

1
*.gwt.rpc

This file defines:

  • Classes allowed for deserialization
  • Serializable fields
  • Serialization UIDs

Key test case:

Attempt direct access:

1
/module/XXXXXXXX.gwt.rpc

If accessible, it may reveal entries such as:

1
2
3
com.example.server.AdminUser
java.util.HashMap
...

This effectively discloses the server-side deserialization allowlist.

5. Parameter Tampering Attacks

GWT RPC being strongly typed does not imply it is secure.

Attack vector 1: Authorization bypass

Example:

1
updateUser(userId=1001)

Modify to:

1
updateUser(userId=1)

If the backend fails to enforce:

1
if (currentUser.id == userId)

You have a classic horizontal privilege escalation.

Attack vector 2: Parameter mutation

Despite strong typing, parameters remain attacker-controlled.

You can mutate:

  • String
  • long
  • boolean
  • List sizes
  • Map key/value pairs

Test for:

  • Null handling
  • Overlong strings
  • Negative values
  • Special characters
  • Nested object boundaries

6. Type Confusion (Advanced)

GWT RPC embeds type identifiers such as:

1
java.lang.String/2004016611

The numeric suffix corresponds to the serialVersionUID.

Attack vector: Type substitution

If multiple classes are allowed by policy, you may replace:

1
com.example.dto.UserDTO

with:

1
com.example.dto.AdminDTO

Conditions:

  • AdminDTO is in the SerializationPolicy allowlist
  • Method parameter type is a superclass or Object

This frequently leads to privilege escalation.

7. Java Deserialization Exploitation

This is the most critical risk area in GWT RPC.

The request processing flow involves:

1
com.google.gwt.user.server.rpc.RPC.decodeRequest

Ultimately leading to Java object construction.

Preconditions:

  1. A usable gadget chain exists in the server classpath
  2. The class is allowed by SerializationPolicy
  3. Attacker-controlled fields trigger the chain

Exploitation workflow

  1. Obtain the SerializationPolicy
  2. Identify dangerous classes such as:
1
2
java.util.HashMap
org.apache.commons.collections...
  1. Construct a gadget chain
  2. Manually assemble a valid GWT RPC payload

Historically, older GWT deployments combined with vulnerable Commons Collections versions were exploitable for RCE.

The exploitation model mirrors traditional Java deserialization attacks.

8. strongName Validation Weaknesses

strongName is a front-end compilation hash.

Test whether:

  • The server validates it strictly
  • It can be replayed
  • It can be reused across users

Many systems only verify format rather than authenticity.

9. Automation Strategy

From an engineering perspective, you can build a GWT RPC fuzzing framework with modules to:

  1. Parse the string table automatically
  2. Replace parameters programmatically
  3. Recalculate index offsets
  4. Reconstruct valid payloads

Mutation targets:

  • Parameter value fuzzing
  • Type substitution
  • Null injection
  • Collection size abuse
  • Deep object nesting

10. Common Vulnerability Categories

Vulnerability Type Likelihood Impact
Authorization bypass Very high High
Deserialization RCE Medium Critical
Information disclosure High Medium
Type confusion Medium High
Business logic flaws Very high High

11. Defensive Recommendations

From a blue-team perspective:

  • Strictly validate strongName
  • Prevent exposure of .gwt.rpc files
  • Enforce authorization at the Service layer
  • Avoid Object-typed parameters
  • Minimize deserializable class surface
  • Upgrade GWT versions
  • Eliminate dangerous gadget-bearing dependencies

12. Practical Takeaways

The core issue in GWT RPC security is not the protocol itself, but a flawed assumption:

Strong typing does not equal strong security.

In real-world engagements:

  • ~80% are authorization issues
  • ~15% are business logic flaws
  • ~5% are full deserialization RCE

However, that 5% typically results in complete system compromise.