Skip to content

Horizontal & Vertical Access Control

Bron: PortSwigger Web Security Academy Auteur: Johan Beysen | Fox & Fish Cybersecurity

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?
Richtingen 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. Lab — Multi-Step Process Bypass

Beschrijving

This lab has an admin panel with a flawed multi-step process for changing a user's role. You can familiarize yourself with the admin panel by logging in using the credentials administrator:admin.

To solve the lab, log in using the credentials wiener:peter and exploit the flawed access controls to promote yourself to become an administrator.

Aanpak

  1. Log in als administrator:admin
  2. Voer een role-upgrade actie uit op een user
  3. Onderschep beide POST requests in Burp:
    • Request 1: de upgrade-aanvraag
    • Request 2: de bevestiging ("Are you sure? YES")
  4. Log in als wiener:peter
  5. Stuur Request 2 opnieuw — maar nu met de cookie van wiener

Kwetsbaarheid

De developer ging ervan uit dat je Request 2 enkel bereikt nadat je Request 1 als admin hebt uitgevoerd. Maar HTTP heeft geen state — elke request staat op zichzelf.

Request 2 had geen eigen autorisatiecheck → bevestigingsstap uitvoerbaar door iedereen die de request kent.

Kernles

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

Vraag

Q: Hoe kan een aanvaller aan die POST requests komen als hij niet aangemeld was als admin?

A: Via meerdere methoden:

  • Brute force/fuzzing van het endpoint (/admin/promote/confirm)
  • JS broncode analyse — admin-paden staan soms hardcoded in JS bestanden
  • Gemeenschappelijke naming conventions — als /admin/promote bestaat, bestaat /admin/promote/confirm wellicht ook
  • Other user's account als die al eerder een promote-actie heeft gedaan (via gedeelde logboeken of lekken)

Fox & Fish Cybersecurity | Intern gebruik