Authorization Bypass — Impossible
Hoe beveilig je een systeem dan wél tegen Insecure Direct Object References?
1. Predict (Voorspel)
De back-end (PHP) code is aangepast. Wanneer de server een verzoek krijgt voor klant_id=4593, kijkt hij niet meer alleen naar dát nummer.
De server doet nu het volgende in de achtergrond:
$gevraagd_id = $_POST['id'];
$mijn_echte_id = $_SESSION['user_id']; // Uit de onkraakbare sessie
if ($gevraagd_id !== $mijn_echte_id && !is_admin($mijn_echte_id)) {
die("Toegang geweigerd!");
}
Vraag: Waarom kun je deze beveiliging niet via F12 of externe tools manipuleren?
Antwoord
De server vertrouwt niet langer blindelings op de data die door de browser (Client-Side) wordt ingestuurd. De server vergelijkt de gevraagde data nu met de $_SESSION van de gebruiker. Sessie-variabelen staan op de webserver opgeslagen en kunnen door een externe bezoeker op geen enkele manier vervalst of uitgelezen worden. Dit is echte "Server-Side Validatie"!
2. Run & Investigate
Start het lab hieronder.
Probeer via de Developer Tools je ID te vervalsen. Je zult zien dat de server "Toegang Geweigerd" of iets vergelijkbaars teruggeeft, omdat hij nu controleert of jij echt recht hebt op de data die je opvraagt.
3. ✓ Wat moest je zien?
- Met je eigen ID werkt de pagina prima — je krijgt netjes je eigen profiel.
- Met een vervalst ID via F12 krijg je "Toegang geweigerd" (of een lege response), nooit het profiel van iemand anders.
- De server kijkt naar
$_SESSION, niet naar de POST-body — wat je ook in de browser knutselt, je sessie blijft van jezelf.
Krijg je tóch andermans profiel? Controleer dat het level-bordje op Impossible staat — anders draait nog Low/Medium/High.
Wat heb je geleerd?
- Vertrouw nooit data uit de frontend: Alles wat uit de browser komt (HTML velden, dropdowns, JavaScript variabelen) kan door een bezoeker vervalst worden.
- Autorisatie is Server-Side: Controles of een gebruiker bij specifieke data mag komen, moeten altijd op de backend webserver gebeuren, gebaseerd op onvervalsbare sessiegegevens.