Challenge Overview
| Field | Value |
|---|---|
| Name | Space Explorer |
| Category | Web |
| Difficulty | Easy |
| Target | http://<target_ip>:<port> |
| Concept | JSON deserialization differential between a Go frontend and a Python backend |
Flag
| Type | Value |
|---|---|
| Challenge flag | [REDACTED] |
Reconnaissance / Analysis
- Opened the web application by its IP in a browser.
- Viewed the page source.
- Key observation: the stack mixes two languages — Go (frontend/gateway) and Python (backend). The two components deserialize the same JSON request differently.
- This is the classic setup for a JSON-parser differential bug:
- Go's
encoding/jsonmatches struct fields case-insensitively, and for duplicate keys that map to the same field the last value wins. - Python's
json.loadsis case-sensitive, soactionandActionare treated as two distinct keys.
The mismatch means one component can authorize a request on one key while the other executes on a different, near-identical key.
Exploitation
Send a JSON body with two near-duplicate keys differing only by case. One component authorizes the request on action (getSecureCode — allowed), while the other executes Action (getcosmic — the privileged action that returns the flag).
Step 1 — Duplicate-key JSON request
curl -s -X POST http://<target_ip>:<port>/execute \
-H "Content-Type: application/json" \
-d '{"action":"getSecureCode","Action":"getcosmic"}'
Result
The getcosmic action is executed on the backend despite only getSecureCode being authorized, and the flag is returned in the response.
FLAG FOUND
Techniques Demonstrated
- Stack fingerprinting (Go + Python dual backend)
- JSON deserialization differential — duplicate key + case sensitivity → authorization bypass
Tools Used
Browser (view-source), curl
← all writeups