Inloggegevens bestaan uit twee helften: de gebruikersnaam en het wachtwoord. Kent de aanvaller de eerste al, dan concentreert hij zijn pogingen op echte accounts in plaats van op willekeurige namen. Gebruikersenumeratie is dus een klassieke verkenningsstap, ter voorbereiding van een brute-force-aanval of credential stuffing. De testgids van OWASP rekent het tot de controles op identiteitsbeheer.
Hoe enumeratie werkt
De aanvaller zoekt een verschil in gedrag tussen een account dat bestaat en een account dat niet bestaat. OWASP noemt er verschillende:
- een andere foutmelding voor "onbekende gebruikersnaam" en "onjuist wachtwoord";
- een HTTP-statuscode, antwoordgrootte of paginatitel die verschilt;
- een langere responstijd als het account bestaat, bijvoorbeeld omdat er een resetmail wordt verstuurd;
- een gebruikersspecifiek adres dat 403 geeft als de gebruiker bestaat en anders 404;
- een formulier voor een vergeten wachtwoord dat het bestaan van het account bevestigt of ontkent.
Het principiële verweer is overal hetzelfde: geef in alle gevallen identieke meldingen en antwoorden.
De bronnen van enumeratie in WordPress
WordPress publiceert standaard verschillende gegevens die naar gebruikersnamen leiden. De slug van een auteur (user_nicename) wordt afgeleid van de gebruikersnaam: wie de slug kent, kent dus vaak ook de gebruikersnaam.
/?author=1stuurt door naar het auteursarchief, waarin de slug staat.- De REST API (
/wp-json/wp/v2/users) geeft voor auteurs die iets hebben gepubliceerd het numerieke ID, de weergavenaam en de slug. In 2017 kreeg WordPress 4.7 zelfs CVE-2017-5487 toegewezen voor een te ruime lijst, opgelost in 4.7.1. - De sitemap van gebruikers (
wp-sitemap-users-1.xml), aanwezig sinds WordPress 5.5. - oEmbed-antwoorden, met de naam en de link naar het auteursarchief.
- Het inlogformulier, dat een onbekende gebruikersnaam onderscheidt van een onjuist wachtwoord.
Ons artikel over gebruikersenumeratie in WordPress laat zien hoe je elk van die bronnen in twee minuten op je eigen site test, en het artikel over de REST API legt uit hoe je de gebruikersroute afsluit voor anonieme bezoekers zonder de editor te breken.
Voor WordPress: zo bescherm je je
- Publiceer niet met een beheerdersaccount: maak een account met de rol Auteur of Redacteur om te schrijven. Een account dat niets heeft gepubliceerd, verschijnt niet in de API, de sitemap of de archieven.
- Kies onder Gebruikers, Profiel bij "Openbaar weergeven als" een naam die verschilt van de gebruikersnaam (de slug verandert daarmee niet).
- Sluit overbodige bronnen af: auteursarchieven, de REST-route voor gebruikers voor anonieme bezoekers, de provider
usersvan de sitemap, de auteur in oEmbed-antwoorden. - Maak de foutmelding bij het inloggen algemeen.
Houd het wel in verhouding: een gebruikersnaam is geen geheim. Een lang, uniek wachtwoord en tweefactorauthenticatie beschermen het account ook als de naam bekend is; de gebruikersnaam verbergen ontneemt de aanvaller alleen een gratis voordeel.
De module Hardening van WP Masquerade Pro sluit die bronnen met een enkele optie af: /?author= en auteursarchieven, de REST-route voor gebruikers voor anonieme bezoekers, de sitemap van de auteurs, de auteur in oEmbed-antwoorden en neutrale foutmeldingen. Ingelogde gebruikers en de andere REST-routes blijven gewoon werken. Namen die elders verschijnen (artikelsignatuur, thema, e-mailadres) blijven zichtbaar.