IDOR (Insecure Direct Object Reference)

Reading time: 5 minutes

tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) εμφανίζεται όταν ένα web ή API endpoint αποκαλύπτει ή δέχεται έναν αναγνωριστικό που ελέγχεται από τον χρήστη και ο οποίος χρησιμοποιείται απευθείας για πρόσβαση σε ένα εσωτερικό αντικείμενο χωρίς να επαληθεύει ότι ο καλών έχει εξουσιοδότηση να έχει πρόσβαση/τροποποίηση σε αυτό το αντικείμενο. Η επιτυχημένη εκμετάλλευση συνήθως επιτρέπει horizontal or vertical privilege-escalation, όπως το να διαβάσει ή να τροποποιήσει δεδομένα άλλων χρηστών και, στη χειρότερη περίπτωση, full account takeover ή mass-data exfiltration.

1. Εντοπισμός πιθανών IDORs

  1. Αναζητήστε παραμέτρους που αναφέρονται σε ένα αντικείμενο:
  • Διαδρομή: /api/user/1234, /files/550e8400-e29b-41d4-a716-446655440000
  • Ερώτημα: ?id=42, ?invoice=2024-00001
  • Σώμα / JSON: {"user_id": 321, "order_id": 987}
  • Κεφαλίδες / Cookies: X-Client-ID: 4711
  1. Δώστε προτεραιότητα σε endpoints που διαβάζουν ή ενημερώνουν δεδομένα (GET, PUT, PATCH, DELETE).
  2. Σημειώστε πότε οι αναγνωριστικοί είναι σειριακοί ή προβλέψιμοι – αν το ID σας είναι 64185742, τότε 64185741 πιθανότατα υπάρχει.
  3. Εξερευνήστε κρυφές ή εναλλακτικές ροές (π.χ. σύνδεσμος "Paradox team members" σε σελίδες login) που μπορεί να αποκαλύψουν επιπλέον APIs.
  4. Χρησιμοποιήστε μια authenticated low-privilege session και αλλάξτε μόνο το ID κρατώντας το ίδιο token/cookie. Η απουσία σφάλματος εξουσιοδότησης συνήθως είναι ένδειξη IDOR.

Γρήγορος χειροκίνητος χειρισμός (Burp Repeater)

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

{"lead_id":64185741}

Αυτοματοποιημένη enumeration (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

Όταν ένα download endpoint δέχεται τόσο ένα username όσο και ένα filename (π.χ. /view.php?username=<u>&file=<f>), μικρές διαφορές στα μηνύματα σφάλματος συχνά δημιουργούν ένα oracle:

  • Μη υπάρχον username → "User not found"
  • Κακό filename αλλά έγκυρη extension → "File does not exist" (μερικές φορές επίσης εμφανίζει διαθέσιμα αρχεία)
  • Κακή extension → validation error

Με οποιαδήποτε authenticated session, μπορείτε να fuzz το username parameter ενώ κρατάτε ένα benign filename και να φιλτράρετε με βάση το "user not found" string για να ανακαλύψετε valid users:

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'

Μόλις εντοπιστούν έγκυρα ονόματα χρήστη, ζητήστε συγκεκριμένα αρχεία απευθείας (π.χ., /view.php?username=amanda&file=privacy.odt). Αυτό το μοτίβο συχνά οδηγεί σε μη εξουσιοδοτημένη αποκάλυψη εγγράφων άλλων χρηστών και credential leakage.

2. Πραγματική Μελέτη Περίπτωσης – McHire Chatbot Platform (2025)

Κατά την αξιολόγηση του Paradox.ai-powered McHire recruitment portal, εντοπίστηκε το ακόλουθο IDOR:

  • Endpoint: PUT /api/lead/cem-xhr
  • Authorization: user session cookie for any restaurant test account
  • Body parameter: {"lead_id": N} – 8-ψήφιος, σειριακός αριθμητικός αναγνωριστής

Μειώνοντας το lead_id ο ελεγκτής απέκτησε αυθαίρετα το πλήρες PII των υποψηφίων (name, e-mail, phone, address, shift preferences) καθώς και ένα καταναλωτικό JWT που επέτρεψε session hijacking. Η καταμέτρηση του εύρους 1 – 64,185,742 αποκάλυψε περίπου 64 million records.

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}'

Σε συνδυασμό με default admin credentials (123456:123456) που παρείχαν πρόσβαση στον δοκιμαστικό λογαριασμό, η ευπάθεια οδήγησε σε κρίσιμη παραβίαση δεδομένων σε επίπεδο εταιρείας.

3. Επιπτώσεις του IDOR / BOLA

  • Οριζόντια κλιμάκωση – ανάγνωση/ενημέρωση/διαγραφή δεδομένων άλλων χρηστών.
  • Κάθετη κλιμάκωση – χρήστης με χαμηλά προνόμια αποκτά λειτουργίες μόνο για admin.
  • Μαζική παραβίαση δεδομένων αν τα αναγνωριστικά είναι διαδοχικά (π.χ., applicant IDs, invoices).
  • Κατάληψη λογαριασμού με κλοπή tokens ή επαναφορά κωδικών άλλων χρηστών.

4. Μέτρα μετριασμού & Καλές πρακτικές

  1. Επιβάλλετε εξουσιοδότηση σε επίπεδο αντικειμένου σε κάθε αίτημα (user_id == session.user).
  2. Προτιμήστε έμμεσα, μη-μάντεψιμα αναγνωριστικά (UUIDv4, ULID) αντί για auto-increment IDs.
  3. Εκτελέστε την εξουσιοδότηση server-side, μην βασίζεστε σε κρυφά πεδία φορμών ή ελέγχους UI.
  4. Εφαρμόστε ελέγχους RBAC / ABAC σε ένα κεντρικό middleware.
  5. Προσθέστε rate-limiting & logging για να ανιχνεύσετε την enumeration αναγνωριστικών.
  6. Κάντε security tests σε κάθε νέο endpoint (unit, integration, και DAST).

5. Εργαλεία

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

Αναφορές

tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks