Skip to content

Horizontal & Vertical Access Control

Auteur: Johan Beysen

1. Vertical Access Control

Vertical Access Control gaat over privilege levels en rollen:

  • Admin vs User vs Guest
  • "Mag ik deze functie uitvoeren op basis van mijn rol?"
  • Typisch voorbeeld: een gewone user probeert het admin panel te bereiken

Hiërarchisch denken: "Ben ik belangrijk genoeg?"

2. Horizontal Access Control

Horizontal Access Control gaat over ownership binnen hetzelfde level:

  • User A vs User B (beiden met de rol "user")
  • "Mag ik deze specifieke resource benaderen?"
  • Typisch voorbeeld: user A probeert user B's profiel te bewerken

Lateraal denken: "Is dit van mij?"

3. Vergelijking

Vertical Horizontal
Vraag Ben ik bevoegd genoeg? Is dit object van mij?
Richting Hiërarchisch (omhoog/omlaag) Lateraal (zijwaarts)
Voorbeeld aanval User escaleert naar admin User A leest data van User B
OWASP naam Broken Function Level Authorization BOLA / IDOR

Beide kunnen over functies én resources gaan

  • Vertical: Admin mag alle user records zien (resource) én users verwijderen (functie)
  • Horizontal: User A mag zijn eigen profiel bewerken (functie) én zijn eigen orders zien (resource)

4. In IDOR Context

Kwetsbaarheid Type
User escaleert naar admin Missing vertical AC
User A leest user B's data Missing horizontal AC (IDOR)

5. Multi-Step Process Bypass

Kwetsbaarheid

De developer veronderstelt dat stap 2 enkel bereikbaar is nadat stap 1 correct doorlopen werd. Maar HTTP heeft geen state — elke request staat op zichzelf.

Stap 1: POST /admin/promote          → 403   (autorisatiecheck aanwezig)
Stap 2: POST /admin/promote/confirm  → 200 OK (geen check op deze stap)

Stap 2 heeft geen eigen autorisatiecheck → de bevestigingsstap is uitvoerbaar door iedereen die de request kent.

Aanpak

  1. Log in als admin, voer de volledige flow uit
  2. Intercept beide requests in Burp
  3. Log in als gewone user
  4. Stuur stap 2 opnieuw — met de sessiecookie van de gewone user

Kernles

Elke stap in een multi-step flow moet afzonderlijk geautoriseerd worden. Nooit veronderstellen dat de volgorde gerespecteerd wordt.

Hoe vindt een aanvaller de stap-2 request?

  • Brute force / fuzzing van het endpoint — als /admin/promote bestaat, bestaat /admin/promote/confirm wellicht ook
  • JS broncode analyse — admin-paden staan soms hardcoded in JavaScript bestanden
  • Naming conventions — voorspelbare URL-patronen (/confirm, /execute, /finalize)
  • Eerder onderschepte requests — via gedeelde omgevingen of lekken in logbestanden