Broken authentication: authenticatie- en sessiezwakheden testen in een pentest

Broken access control krijgt sinds de laatste OWASP Top 10 de meeste aandacht, maar authenticatie- en sessiezwakheden blijven een categorie waar wij tijdens webapplicatie-pentests bijna altijd iets vinden. De categorie heet in de OWASP Top 10 formeel "Identification and Authentication Failures" (A07), maar in de wandelgangen spreken we nog steeds over broken authentication. Het gaat om alles wat misgaat rondom de vraag "ben je wie je zegt dat je bent" en "hoe houden we die identiteit vast gedurende een sessie". Een fout hier is zelden theoretisch: het leidt vrijwel altijd tot volledige accountovername. In dit artikel beschrijven we de zwakheden die wij in de praktijk het vaakst zien, hoe een pentester ze test en welke maatregelen echt helpen.

## Waarom authenticatie zo vaak misgaat

Authenticatie lijkt een opgelost probleem. Er zijn volwassen frameworks, identity providers en libraries die het zware werk doen. Toch gaat het regelmatig mis, en dat heeft een aantal terugkerende oorzaken. Ontwikkelaars bouwen zelf een inlogflow omdat de standaardoplossing net niet paste. Een registratie- of wachtwoordherstelfunctie wordt sneller in elkaar gezet dan de eigenlijke login en krijgt minder aandacht. Of een applicatie is over de jaren gegroeid, waarbij nieuwe authenticatiemethoden zijn toegevoegd zonder dat de oude netjes zijn uitgefaseerd. Het resultaat is dat de aanvalsoppervlakte rond authenticatie breder is dan alleen het inlogscherm.

Belangrijk om te begrijpen: authenticatie en sessiebeheer zijn twee kanten van dezelfde medaille. Authenticatie bewijst eenmalig wie je bent, sessiebeheer zorgt dat de applicatie dat bewijs onthoudt bij elk volgend verzoek. Een sterke login met zwak sessiebeheer is net zo lek als een zwakke login. Daarom testen wij ze altijd in samenhang.

## Zwakke plekken die wij het vaakst tegenkomen

### Ontbrekende bescherming tegen brute force en credential stuffing

Veel applicaties beperken het aantal inlogpogingen niet of nauwelijks. Dat maakt niet alleen klassieke brute force mogelijk, maar vooral credential stuffing: het geautomatiseerd uitproberen van gebruikersnaam-wachtwoordcombinaties uit eerdere datalekken. Omdat mensen wachtwoorden hergebruiken, is dit in de praktijk een van de meest succesvolle aanvalsvormen.

### Zwak wachtwoordbeleid en voorspelbare herstelmechanismen

Applicaties die korte of veelvoorkomende wachtwoorden accepteren, verlagen de lat voor een aanvaller. Minstens zo riskant is de wachtwoordherstelfunctie. Voorspelbare reset-tokens, tokens die niet verlopen, of een "geheime vraag" met een antwoord dat op LinkedIn te vinden is, geven een aanvaller een achterdeur die de eigenlijke login volledig omzeilt.

### Multifactor-authenticatie die te omzeilen is

MFA is een sterke maatregel, maar alleen als het correct is geïmplementeerd. Wij komen implementaties tegen waarbij de tweede factor via een parameter in het verzoek te overslaan is, waarbij de MFA-controle client-side gebeurt, of waarbij de one-time-passcode onbeperkt vaak geprobeerd mag worden. Ook het herstelpad rondom MFA is een klassiek zwak punt: als je MFA kunt resetten met alleen een e-mailadres, is de meerwaarde beperkt.

### Sessietokens die niet veilig zijn

Een sessietoken hoort onvoorspelbaar, voldoende lang en willekeurig te zijn. Wij zien nog steeds tokens die oplopende getallen bevatten, of die informatie over de gebruiker prijsgeven. Ook de manier waarop tokens worden opgeslagen doet ertoe: een sessiecookie zonder de attributen HttpOnly, Secure en SameSite is kwetsbaar voor diefstal via cross-site scripting of via onversleutelde verbindingen.

### Sessies die niet correct eindigen

Een veelgemaakte fout is dat uitloggen de sessie aan de serverkant niet ongeldig maakt. Het token blijft dan bruikbaar, ook nadat de gebruiker denkt te zijn uitgelogd. Andere varianten: sessies zonder verloop, sessies die na een wachtwoordwijziging actief blijven, en het ontbreken van sessievernieuwing na een succesvolle login, waardoor session fixation mogelijk wordt.

## Hoe een pentester dit test

Onze aanpak begint met het volledig in kaart brengen van de authenticatiefunctionaliteit: registratie, login, wachtwoordherstel, MFA-inschrijving, sessieverloop en uitloggen. Elk van die flows is een potentieel toegangspad.

Voor brute force en rate limiting kijken we hoeveel pogingen een applicatie toestaat en of er sprake is van vertraging, blokkade of een captcha na een aantal foute pogingen. We letten daarbij op subtiele verschillen in foutmeldingen. Een applicatie die bij een onbekende gebruiker "gebruiker bestaat niet" toont en bij een bestaande gebruiker "wachtwoord onjuist", geeft ongewild prijs welke accounts bestaan. Dat heet user enumeration en versnelt een gerichte aanval.

Sessietokens onderzoeken we op willekeur en structuur. We verzamelen meerdere tokens en analyseren of er een patroon in zit. We controleren de cookie-attributen, testen of een token na uitloggen nog werkt, of een oude sessie geldig blijft na een wachtwoordwijziging, en of de applicatie een nieuw token uitgeeft na een succesvolle login. Voor MFA proberen we de tweede factor te omzeilen door verzoeken te manipuleren, en testen we of de one-time-passcode aan een limiet gebonden is.

Cruciaal is dat we bevindingen niet alleen technisch vaststellen, maar ook de daadwerkelijke impact aantonen. Een aanvalsketen waarbij user enumeration, ontbrekende rate limiting en een zwak wachtwoordbeleid samen tot accountovername leiden, is voor een opdrachtgever veel overtuigender dan drie losse observaties. Die context bepaalt ook de prioritering in het herstel.

## Hoe je het structureel voorkomt

De belangrijkste maatregel is het niet zelf bouwen van authenticatie waar een volwassen alternatief bestaat. Gebruik een beproefde identity provider of framework en houd die up-to-date. Voer overal rate limiting en bescherming tegen credential stuffing in, en overweeg het controleren van wachtwoorden tegen bekende datalekken. Hanteer een wachtwoordbeleid dat aansluit op moderne richtlijnen: lengte boven complexiteit, en geen gedwongen periodieke wijzigingen zonder aanleiding.

Zet multifactor-authenticatie aan voor gevoelige functies en implementeer die server-side, met een limiet op het aantal pogingen. Zorg dat sessietokens willekeurig en voldoende lang zijn, sla ze op in cookies met HttpOnly, Secure en SameSite, en geef na elke login een nieuw token uit. Maak sessies aan de serverkant ongeldig bij uitloggen, na een wachtwoordwijziging en na een periode van inactiviteit. Behandel wachtwoordherstel met dezelfde zorg als de login zelf, met kortlevende, eenmalig bruikbare tokens.

Tot slot: laat deze maatregelen periodiek toetsen. Authenticatie verandert mee met de applicatie, en een pentest is de manier om vast te stellen of de theorie ook in de praktijk klopt. Na herstel voeren wij standaard een retest uit om te bevestigen dat de bevindingen daadwerkelijk zijn opgelost en dat er geen nieuwe zwakheden zijn geïntroduceerd.

Secure Audit voert webapplicatie-pentests uit waarbij authenticatie en sessiebeheer een vast onderdeel zijn van de scope. We leveren concrete, reproduceerbare bevindingen met hersteladvies en een retest. Neem contact op voor een vrijblijvend gesprek over jouw applicatie.