Ga naar hoofdinhoud

CSRF — High

Om Referer-bypasses en CSRF definitief de kop in te drukken, grijpt de ontwikkelaar naar een token-systeem.

1. Predict (Voorspel)​

De server dwingt nu af dat elk request een uniek token meebrengt (een willekeurige code). Het formulier ziet er achter de schermen zo uit:

<input type="hidden" name="user_token" value="2d8b8e...e10">

De backend controleert dit strak:

checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ] );

Vraag: Waarom is het voor een hacker onmogelijk om een kwaadaardige URL (<img src="...password=hacked">) te bouwen voor het slachtoffer als deze beveiliging actief is?

Antwoord

Om het wachtwoord te wijzigen, moet het verzoek nu het geheime token bevatten (&user_token=...). Omdat dit token voor elke sessie uniek en willekeurig is, kan de hacker deze code onmogelijk raden. De CSRF aanval loopt direct stuk op een 'Token Mismatch' fout!

2. Run & Investigate​

Start het lab.

Laden...

Probeer de kwetsbaarheid van het Low niveau (door de URL handmatig aan te passen) in de adresbalk. Het zal falen omdat je de user_token niet goed kunt raden/meesturen in je fake linkje.

3. Modify & Make (Aanpassen & Maken)​

Een anti-CSRF token is steengoed, maar is kansloos als de website ook kwetsbaar is voor een andere veelvoorkomende bug: XSS!

Hoe zou een hacker een XSS kwetsbaarheid (ergens anders op dezelfde website) kunnen gebruiken om de anti-CSRF token-beveiliging van het wachtwoordveld teniet te doen?

Tip

XSS zorgt ervoor dat de hacker code kan draaien namens het slachtoffer binnen in de webpagina zelf.

Antwoord

Via XSS injecteert de hacker een klein JavaScriptje op de pagina van het slachtoffer. Dit script laadt stiekem de "Wachtwoord Veranderen" pagina op de achtergrond. Het scriptje leest het user_token direct uit de opgevraagde HTML (wat mag, want de browser is van het slachtoffer), vult dat token in, en verstuurt direct daarna het request om het wachtwoord te wijzigen!

4. ✓ Wat moest je zien?​

Controle
  • Een directe URL-aanval (zoals op Low) levert nu "CSRF token is incorrect" of een vergelijkbare token-mismatch-melding.
  • In F12 Elements zie je het verborgen veld <input type="hidden" name="user_token" value="…"> met een lange willekeurige string die bij elke pageload verandert.
  • Een normale wachtwoordwijziging via het formulier werkt nog steeds — het token wordt dan automatisch meegestuurd.

Slaagt een directe URL-aanval tóch? Controleer dat het level rechtsboven op High staat. Het token wordt anders niet afgedwongen.