HTB Space Explorer Writeup

The challenge description mentions a flawed authentication logic between the Sender and Receiver services, which hints that both services might be interpreting our request differently.

The application sends the following JSON:

{
    "action": "getcosmic"
}

I first tried the usual things like isAdmin: true, header manipulation, and URL parameters, but none of them worked. Since the source code was available, I switched to analyzing the backend.

The application consists of two services:

• Go (Sender) – validates the request.
• Python (Receiver) – processes it.

In Go, the request is parsed using json.Unmarshal() and checked with:

switch requestData.Action

If the action is valid, Go forwards the original request body using:

bytes.NewBuffer(body)

This means Python receives the exact request body we sent, not the value Go selected after parsing it.

Get Raviaravindhan Official’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The vulnerability comes from the way both languages parse JSON:

• Go's encoding/json is case-insensitive when matching JSON keys to struct fields.
• Python dictionaries are case-sensitive.

Using the following payload:

{
    "action": "getSecureCode",
    "Action": "getcosmic"
}

Go treats both keys as the same field, so the last matching key wins, resulting in:

requestData.Action = getcosmic

The request passes the switch check and is forwarded.

Python, however, treats action and Action as different keys, so:

data["action"] == "getSecureCode"

which returns the flag.

Note: Reversing the order doesn't work because Go keeps the value of the last matching key, causing the switch check to fail before the request reaches Python.

Final Thoughts

This challenge was a nice introduction to JSON parser differentials. It shows how two services can interpret the same JSON differently, leading to an authentication bypass.