De elegantste hacks zijn vaak de simpelste. Geen buffer overflows, geen race conditions, geen ingewikkelde exploit chains. Gewoon: verander het getal in de URL.
GET /api/orders/7842 — je eigen bestelling. Prima.
GET /api/orders/7843 — de bestelling van iemand anders. Oeps.
Dit is Broken Object Level Authorization, liefkozend BOLA genoemd, en het is al jaren de nummer één API-kwetsbaarheid ter wereld. Niet omdat het moeilijk te begrijpen is. Niet omdat het moeilijk te voorkomen is. Maar omdat ontwikkelaars het consequent vergeten.
Waarom gebeurt dit zo vaak?
In een typisch webframework schrijf je een route: /api/orders/:id. Het framework parseert het ID uit de URL, zoekt het op in de database, en stuurt het terug. De database vindt het. Het object bestaat. De server stuurt het op. Nergens in dit proces stelt iemand de vraag: "Maar is dit jouw bestelling?"
Het is alsof een hotel je kamersleutel geeft en zegt: "Alle deuren gebruiken hetzelfde slot. We vertrouwen erop dat je alleen je eigen kamer binnengaat."
Bij kleine applicaties valt het niet op. Bij grotere applicaties, met tientallen endpoints en honderden objecttypen, is het bijna onvermijdelijk dat ergens een check ontbreekt. Eén endpoint. Eén vergeten if-statement. Dat is alles wat nodig is.
Hoe vind je BOLA?
Bij een pentest is BOLA-testen bijna beschamend eenvoudig:
- Log in als gebruiker A.
- Doe een normale actie (bekijk je bestelling, je profiel, je factuur).
- Pak het ID uit de request.
- Log in als gebruiker B.
- Verstuur dezelfde request met het ID van gebruiker A.
- Als je de data van gebruiker A te zien krijgt: BOLA.
Dat is het. Geen speciale tools. Geen diepgaande technische kennis. Een browser met ontwikkelaarstools is genoeg. En toch vinden pentesters dit in vrijwel elke API die ze testen.
Varianten
IDOR: de klassieker
Insecure Direct Object Reference — het originele probleem. Voorspelbare, sequentiële ID's (1, 2, 3, ...) maken het extra eenvoudig om door andermans data te bladeren.
UUID's zijn geen beveiliging
De reflex is vaak: "We gebruiken UUID's, dus het is niet te raden." UUID's maken het lastiger, niet onmogelijk. Ze lekken via logs, URL's, foutmeldingen en andere API-responses. UUID's zijn obscurity, geen security.
Bulk-operaties
Endpoints die meerdere objecten tegelijk retourneren (/api/orders?user_id=123) vergeten soms te controleren of je die user_id mag opvragen. Eén parameter veranderen en je hebt de complete ordergeschiedenis van een ander.
Hoe voorkom je het?
- Autorisatiecheck op elk endpoint, bij elke request. Niet "als ik eraan denk," maar als architectuurprincipe. Middleware of een decorator die automatisch controleert of de ingelogde gebruiker het gevraagde object mag benaderen.
- Denk in termen van eigenaarschap. Elk object in je database heeft een eigenaar. Elk endpoint controleert of de aanvrager de eigenaar is (of de juiste rol heeft).
- Geautomatiseerde tests. Schrijf tests die expliciét cross-user-toegang proberen. Als gebruiker B de data van gebruiker A kan ophalen, faalt de test.
- Gebruik het framework. De meeste moderne frameworks hebben autorisatie-middleware. Gebruik het. Configureer het. En controleer dat het op elk endpoint actief is.
BOLA is het soort kwetsbaarheid dat je achteraf altijd dom lijkt. "Natuurlijk moet je controleren of iemand dat mag zien." Maar achteraf is het altijd makkelijk. De kunst is om het vooraf te doen, consequent, bij elk endpoint, elke keer.