Wat is IDOR en hoe voorkom je datalekken?
Auteur: Redactie Domeny.ForSale Gepubliceerd
Kort samengevat: IDOR (Insecure Direct Object Reference) is een kwetsbaarheid waarbij een applicatie toegang geeft tot een resource van iemand anders via de identificatiecode ervan, zonder de toegangsrechten goed te controleren. Een gebruiker wijzigt bijvoorbeeld het factuurnummer in het adres en krijgt een document van een andere klant te zien. Het probleem is niet het nummer in het adres, maar dat de server niet controleert of die persoon toegang tot die factuur mag krijgen.
Hoe werkt IDOR? Een eenvoudig voorbeeld
Stel je een klantenportaal voor waarin je na het inloggen je eigen factuur downloadt. De browser stuurt de server een verzoek voor het pad /facturen/481 en de applicatie geeft document 481 terug.
Zo’n adres is op zichzelf heel gebruikelijk. Er ontstaat een kwetsbaarheid als je door het pad te wijzigen in /facturen/482 de factuur van een andere klant kunt downloaden, terwijl je daar geen toegang toe hebt gekregen.
Vergelijk het met een garderobe waar een medewerker een jas meegeeft aan iedereen die het nummer van het haakje noemt, zonder te controleren of die persoon de jas mag ophalen. Het nummer verwijst naar het voorwerp, maar bewijst niet dat iemand het mag meenemen.
Het woord ‘object’ in IDOR staat hier voor een resource van de applicatie: een document, bestelling, foto, bericht of account. ‘Directe verwijzing’ betekent dat die resource via een identificatiecode wordt aangewezen. Dat hoeft geen opeenvolgend nummer te zijn: het kan ook een bestandsnaam, e-mailadres of lange tekenreeks zijn.
Waarom alleen inloggen niet genoeg is
Authenticatie beantwoordt de vraag: ‘Wie ben je?’ Autorisatie, oftewel het controleren van rechten, beantwoordt een andere vraag: ‘Wat mag je doen?’ Een applicatie kan een ingelogde gebruiker correct herkennen en die toch toegang geven tot gegevens van anderen.
Een veilige server moet niet alleen controleren of de factuur bestaat, maar ook of de gebruiker die mag lezen. Toegangsrechten kunnen voortvloeien uit het eigendom van het document, een rol binnen de organisatie of het bewust delen van het document met iemand anders.
IDOR beperkt zich niet tot het bekijken van informatie. Door ontbrekende controle kan iemand ook een resource van een ander wijzigen of verwijderen, bijvoorbeeld het afleveradres in een bestelling. Leesrechten betekenen niet automatisch dat je ook iets mag bewerken. Daarom vereist elke handeling een passende controle.
Als de applicatie door meerdere bedrijven wordt gebruikt, zijn ook de grenzen tussen organisaties belangrijk. Een beheerder van het ene bedrijf mag geen toegang krijgen tot gegevens van het andere bedrijf alleen omdat die de identificatiecode van een document kent.
Waar kan een identificatiecode tot een kwetsbaarheid leiden?
Een identificatiecode hoeft niet zichtbaar te zijn in de adresbalk. Die kan ook staan in queryparameters, in de inhoud van een verzoek dat via een formulier wordt verzonden of in een aanroep van een API: een interface waarmee programma’s met elkaar communiceren.
Veelvoorkomende handelingen die controle vereisen zijn:
- facturen, bijlagen en gegevensexports downloaden;
- berichten, meldingen en bestellingen lezen;
- een profiel of accountinstellingen bijwerken;
- bestanden en andere resources verwijderen.
Niet elke vorm van toegang na het wijzigen van een identificatiecode wijst op een fout. Een openbare blogpost hoort voor iedereen toegankelijk te zijn, en een gedeeld document voor bevoegde collega’s. Er is sprake van een kwetsbaarheid als de beoogde toegangsregels worden overtreden, niet alleen omdat je naar een ander object kunt verwijzen.
Vergelijkbare fouten in een API worden soms aangeduid als BOLA (Broken Object Level Authorization): een gebrekkige controle van de rechten op een specifiek object. De begrippen hangen nauw samen. De praktische vraag blijft dezelfde: controleert de server of de gebruiker recht heeft op toegang tot de opgegeven resource en op het uitvoeren van de gevraagde handeling?
Wat beschermt echt tegen IDOR?
De belangrijkste beveiliging is een controle van de rechten aan de serverkant, telkens wanneer iemand toegang tot een resource vraagt. Een knop verbergen in de interface is niet genoeg, want het verzoek kan ook zonder die knop worden verstuurd.
In het factuurvoorbeeld moet de applicatie het document zoeken binnen de verzameling documenten waartoe de gebruiker toegang heeft, of de rechten controleren voordat ze het document teruggeeft. Een door de browser meegestuurd veld ‘eigenaar’ mag niet als bewijs van eigendom worden vertrouwd.
Willekeurige identificatiecodes, zoals UUID, maken adressen moeilijker te raden, maar vervangen autorisatie niet. Als een identificatiecode uitlekt, bijvoorbeeld via een gedeelde link, moet de server iemand zonder de juiste rechten nog steeds de toegang weigeren.
Een goed uitgangspunt is standaard weigeren: als de applicatie niet kan bevestigen dat iemand een handeling mag uitvoeren, voert ze die niet uit. De controle moet ook het downloaden van bestanden en exports omvatten, niet alleen het hoofdscherm van het document.
Hoe test je je eigen applicatie veilig?
Voer zo’n test alleen uit op een systeem dat van jou is of waarvoor je toestemming hebt om het te testen. Gebruik bij voorkeur een testomgeving en fictieve gegevens, vooral bij het wijzigen en verwijderen van gegevens.
- Maak twee testaccounts aan, A en B, zonder resources met elkaar te delen.
- Maak met account A een document aan en noteer de identificatiecode.
- Log in als B en probeer dat document te lezen via de daarvoor bedoelde interface of API.
- Controleer afzonderlijk of bewerken, downloaden en verwijderen mogelijk zijn, voor zover die handelingen beschikbaar zijn.
- Controleer niet alleen of er een melding verschijnt dat de toegang is geweigerd, maar ook of er geen gegevens zijn vrijgegeven of gewijzigd.
De server moet de ongeoorloofde handeling weigeren. Daarbij kan de server bewust verborgen houden of het document bestaat. Het is zinvol dit scenario aan de geautomatiseerde tests toe te voegen, zodat een codewijziging de kwetsbaarheid niet opnieuw introduceert.
Zie ook: Wat is 2FA?
Lees ook
