IDOR ranjivost: Kada broj u URL-u otvara tuđe podatke

← Blog

Šta je IDOR?

Insecure Direct Object Reference (IDOR) se dešava kada aplikacija koristi identifikator koji kontroliše korisnik (ID, UUID, email, ime fajla) za direktan pristup objektu u bazi bez provere da li logovani korisnik ima pravo pristupa tom objektu.

Klasičan scenario

Korisnik pregleda svoju porudžbinu: https://prodavnica.rs/orders/1247

Menja broj: https://prodavnica.rs/orders/1246

Ako server ne proverava da li porudžbina 1246 pripada logovanom korisniku, napadač vidi tuđu porudžbinu — uključujući ime, adresu i detalje plaćanja.

Realni primeri iz bugbounty programa

• Facebook (2012): IDOR u graph API-ju omogućavao brisanje tuđih fotografija
• Uber (2016): IDOR u putovanjima (trip ID) omogućavao pristup GPS podacima svih korisnika
• Instagram: IDOR u password reset tokenu — mogućnost preuzimanja naloga
• Srpski e-commerce (2024): IDOR u fakturama — pristup finansijskim podacima konkurencije (interno istraživanje)

Tipovi IDOR ranjivosti

URL/Query parameter IDOR

GET /api/users/1042/profile
→ promeni u /api/users/1043/profile

Body parameter IDOR

POST /api/update-address
{"user_id": 1042, "address": "Nova adresa"}
→ promeni user_id u 1043

IDOR putem predvidivog identifikatora

Sekvencijalni ID-ovi (1, 2, 3, ...) su najlakši za eksploatisanje — napadač jednostavno iterira. Ali i UUID-ovi mogu biti predvidivi ako se generišu slabim PRNG-om.

Blind IDOR

Server ne vraća podatke, ali izvršava akciju — npr. brisanje fajla, promena statusa, slanje emaila tuđem nalogu.

Odbrana od IDOR-a

1. Autorizacione provere na svakom zahtevom

Svaki pristup objektu mora biti propraćen proverom: da li logovani korisnik ima pravo pristupa ovom specifičnom objektu?

order = Order.query.get(order_id)
if order.user_id != current_user.id:
    abort(403)  # Forbidden

2. Nikada ne verujte klijentskom ID-u za vlasništvo

Korisnik ne sme da kontroliše user_id ni u query parametrima ni u request body-ju. Uvek koristite ID iz autentifikovanog tokena/sesije.

3. Indirektni identifikatori

Umesto direktnog ID-a iz baze, koristite reference koji imaju smisao samo za tog korisnika — npr. UUID scope-ovan na korisnikovu sesiju.

4. Penetration testing i code review

IDOR zahteva manuelno testiranje: tester mora imati dva različita naloga i testirati pristup resursima jednog naloga sa drugim. Automatski skeneri ovo ne mogu pouzdano detektovati bez aplikacionog konteksta.

5. Logging neuspelih pokušaja pristupa

Ako korisnik pokušava pristupiti resursima koji ne postoje ili mu ne pripadaju, to mora biti zabeleženo. Više od 10 grešaka u kratkom periodu je signal za alarm.

← Blog

What Is IDOR?

Insecure Direct Object Reference (IDOR) occurs when an application uses a user-controlled identifier (ID, UUID, email, filename) for direct access to an object in the database without checking whether the logged-in user has the right to access that specific object.

Classic Scenario

A user views their order: https://shop.com/orders/1247

They change the number: https://shop.com/orders/1246

If the server doesn't verify that order 1246 belongs to the logged-in user, the attacker sees someone else's order — including their name, address, and payment details.

Real Examples from Bug Bounty Programs

• Facebook (2012): IDOR in the Graph API allowed deleting other users' photos
• Uber (2016): IDOR in trips (trip ID) allowed access to GPS data of all users
• Instagram: IDOR in password reset token — ability to take over accounts

Types of IDOR Vulnerabilities

URL/Query Parameter IDOR

GET /api/users/1042/profile
→ change to /api/users/1043/profile

Body Parameter IDOR

POST /api/update-address
{"user_id": 1042, "address": "New address"}
→ change user_id to 1043

Defending Against IDOR

1. Authorization Checks on Every Request

Every object access must be accompanied by a check: does the logged-in user have the right to access this specific object?

order = Order.query.get(order_id)
if order.user_id != current_user.id:
    abort(403)  # Forbidden

2. Never Trust Client-Side ID for Ownership

Users must not control user_id in either query parameters or request body. Always use the ID from the authenticated token/session.

3. Indirect Identifiers

Instead of direct database IDs, use references that only make sense for that user — e.g., UUIDs scoped to the user's session.

4. Penetration Testing and Code Review

IDOR requires manual testing: a tester must have two different accounts and test access to one account's resources with the other. Automated scanners cannot reliably detect this without application context.