hunt-idor

Files (1)

• SKILL.md

SKILL.md (first lines)

# Hunt: IDOR / Broken Object Level Authorization

**Assumes `hunt-core`** for the scope gate, two-account rule, confirmation gate, enumeration
limits, stop conditions, wiki protocol, FIND output, and Deadends. Do not re-derive any of that here.

## Wiki

```
qmd_query "IDOR BOLA insecure direct object reference access control" via wiki-search MCP
```

Hub: [[web-moc]] (live web index). Primary page: [[access-control]]. Payload arsenal: `wiki/payloads/idor.md`.
Anchors: [[uuid-insecurities]] (v1-UUID timestamp/MAC when an object ID is a UUID rather than a
sequential integer), [[jwt-attacks]] (chain a trusted `sub`/`user_id` claim to ATO, hand off to hunt-auth).

## Attack surface signals

URL patterns: `/api/v1/users/{id}`, `/invoices?id=`, `/reports/{uuid}/`, `/messages/{thread_id}`,
`/admin/orgs/{org_id}/members`

GraphQL: any query or mutation taking an `id` argument. Check for `node(id: "...")` global
lookups - one endpoint reaching every object type, with per-type authorization frequently missing
on at least one.

**Rank before testing.** Not all endpoints are equally likely:

- **Newest features** - middleware follows codebase conventions; a feature written outside them
  misses it.
- **Bulk and export endpoints** - one request, many objects, much higher severity per finding.
- **Anything carrying two identifiers** - see the trusted-identifier test below.
- **Cross-service internal calls** - the internal hop often carries no user context at all.
- **File and document access** - frequently a separate host or CDN with no authorization beyond
  knowing the ID.
- **Non-GET verbs on read-looking endpoints** - `GET /orders/123` authorized, `PATCH` not.

## Where the identifiers are

Check all of these; the least obvious are the least protected. Path segments, query parameters,
request bodies (including nested objects), headers (`X-User-Id`, `X-Account-Id`, `X-Tenant-Id`),
cookies, JWT claims, GraphQL variables, WebSocket messages, and file/CDN URLs.

**Get B's identifiers from B.** Log in as B and read them from B's own traffic, profile page, or
JWT. Record in `identities.md`. Never obtain an identifier by incrementing until you find out
whose it is - that is enumerating real users.

**Decode opaque identifiers before assuming they are random.** Base64 and hex frequently decode
to a plain integer or a `type:id` pair. Where the ID is a hash, test whether it hashes something
knowable (email, user ID, timestamp) and compute B's offline.

## UUID: a two-part finding

A random UUID is not an authorization control, but it is a practical barrier. The finding becomes
a chain:

1. **The check is missing** - test with B's UUID, which you legitimately hold.
2. **The UUID is obtainable** - find where it leaks.

Report both together. Part 1 alone gets triaged down as "requires an unguessable identifier."

Leak sources worth working: search and autocomplete endpoints, notification and activity feeds,
team and member lists, verbose errors, notification emails, exported files, share and invite
links, and objects you *can* read that reference objects you cannot.

Also verify the UUID is actually random - v1 encodes timestamp and MAC ([[uuid-insecurities]]),
and hand-rolled implementations frequently emit sequential values dressed as UUIDs.

## Methodology

**Setup:** two accounts per `hunt-core`. A owns, B attacks. Separate profiles.

**Drive it through Burp** for operator visibility. With A's request captured in Repeater or proxy
history:

```
scripts/burp/idor-sweep.py <eng> <reqfile> --attacker-auth "Cookie: session=USER_B" --range 5
```

Sends owner-baseline / idor-test / bounded id sample through `send_http1_request`, diffs status
and body, prints a verdict and a ready `capture.sh burp` PoC line. Honors `no_bruteforce` ->
range 0. **Do not raise `--range` above the `hunt-core` limits without operator approval.**

For GUI-visible replay: `create_repeater_tab` for an A tab and a B tab, or `send_to_intruder`
with a bounded number payload.

1. **Log in as A, browse every feature, note every ID** - object, UUID, org, invoice, thread.
2. **Baseline both directions.** A requests A's object. B requests B's object. Record status,
   length, body shape. You are testing against these, not against intuition.
3. **Cross-request:** B requests A's object with B's session.

```bash
# Baseline - A owns it
curl -s -H "Cookie: session=USER_A" https://target.com/api/v1/invoices/12345

# Cross-account - B attempts
curl -s -H "Cookie: session=USER_B" https://target.com/api/v1/invoices/12345
```

4. **Rule out legitimate access before claiming anything.** Is the object shared with B, in a
   shared team, public, or org-visible? Check the UI as B. This is the single most common false
   positive in this class - an app with sharing features generates them constantly.
5. **Trusted-identifier test - run this on every endpoint carrying two identifiers.** The highest
   value test in IDOR and the most frequently skipped. Make the session and the parameter
   disagree:

```
Session: account B
Body:    {"user_id": "<A's id>", "action": "..."}
```

- Server acts on B -> identity derived from session, parameter ignored. Correct.
- Server acts on A -> **the parameter is trusted.** IDOR, usually critical, fully
  attacker-controlled.
- Server errors on mismatch -> it compares them. Correct, and evasion is the next step.

Apply the same to JWT claims: modify `sub` / `user_id` and see whether the server derives the
acting user from the claim or looks it up. Trusted claim plus weak signature chains to arbitrary
account takeover - hand off to `hunt-auth`.

6. **All verbs.** GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS. Authorization applied per-method

From Encod3d-Sec/TORCH, MIT.

More from Encod3d-Sec/TORCH