User Enumeration

User Enumeration er en sikkerhedssårbarhed, hvor et system utilsigtet afslører, om en bestemt bruger, e-mail eller konto eksisterer. Angrebet bruges typisk som forberedende fase til mere alvorlige angreb som brute force, credential stuffing eller phishing.

Det er lav kompleksitet, men høj strategisk værdi.

Hvad er User Enumeration?

User enumeration opstår, når applikationens respons varierer afhængigt af, om en bruger findes eller ej.

Eksempler:

• “E-mail findes ikke” vs. “Forkert password”

• Forskellig HTTP-statuskode

• Forskellig responstid

• Forskellig fejltekst eller UI-adfærd

Angriberen kan systematisk teste og opbygge en valideret brugerliste.

Hvordan opstår problemet?

Problemet opstår typisk i:

• Login-formularer

• “Glemt password”

• Registreringsflows

• API-endpoints

• Admin-interfaces

Årsagen er næsten altid:

• For detaljeret fejlhåndtering

• Manglende standardisering af svar

• UX-optimering uden sikkerhedsovervejelse

Hvorfor er User Enumeration alvorligt?

Sikkerhed

• Gør målrettede angreb markant lettere

• Reducerer angrebsoverfladen for angriberen

• Forbedrer succesrate for brute force og phishing

Forretning

• Øget risiko for kontoovertagelse

• Tab af kundetillid

• Større konsekvens ved databrud

Compliance

• Kan være i strid med GDPR (persondataeksponering)

• Audit finding ved sikkerhedsgennemgang

Typiske angrebsscenarier

Login

• “User not found” afslører, at e-mailen ikke eksisterer

Password reset

• “Vi har sendt en mail” kun hvis brugeren findes

Registrering

• “Denne e-mail er allerede i brug”

API

• 404 vs. 401/403 afhængigt af brugerens eksistens

Typisk angrebsflow

1. Angriber indsamler e-mails (leaks, LinkedIn, scraping)

2. Tester dem mod applikationen

3. Filtrerer gyldige brugere

4. Iværksætter målrettede angreb

5. Eskalerer ved succes

Hvad beskytter ikke mod User Enumeration?

• CAPTCHA alene

• Rate limiting alene

• Skjult frontend-logik

Hvis backend lækker signaler, er frontend irrelevant.

Best Practice – forebyggelse

Ensartede svar

• Samme fejlbesked uanset årsag

• Samme HTTP-statuskode

• Samme responstid (så vidt muligt)

Eksempel:

“Login mislykkedes. Kontroller dine oplysninger.”

Password reset

• Altid samme besked:

“Hvis kontoen findes, er der sendt en e-mail.”

Rate limiting

• Begræns antal forsøg

• Gælder også for “glemt password”

Logging og overvågning

• Detekter mønstre i enumeration-forsøg

• Alert ved sekventielle tests

Arkitektur

• Undgå eksponering af interne identifikatorer

• Brug opaque IDs

• Valider adgang før eksistens afsløres

Forretningsmæssig realitet

User enumeration virker uskyldigt, men:

• Skalerer ekstremt godt for angribere

• Koster næsten intet at udnytte

• Forværrer alle andre sårbarheder

Det er en force multiplier for angreb.

Udfordringer og løsninger

Udfordring: UX vil være “hjælpsom”

Løsning: Standardiser fejlbeskeder globalt

Udfordring: Legacy-systemer

Løsning: Wrapper-lag der normaliserer svar

Udfordring: API’er bygget til interne formål

Løsning: Antag altid ekstern eksponering

Opsummering

User enumeration handler ikke om adgang, men om information.

Hvis du fortæller, hvem der findes i systemet, hjælper du angriberen gratis.