Gebruikersopsomming voorkomen in WordPress

Gebruikersopsomming (user enumeration) is een verkenningstechniek die aanvallers gebruiken om geldige gebruikersnamen op uw WordPress-site te ontdekken. Het is meestal de eerste stap voor een brute-force-aanval. Als een aanvaller uw beheerdersgebruikersnaam kent, hoeft hij alleen het wachtwoord te raden. Als hij de gebruikersnaam niet kent, is het aanvalsoppervlak aanzienlijk groter. Door opsomming te blokkeren dwingt u aanvallers om zowel de gebruikersnaam als het wachtwoord te raden, wat een succesvolle aanval veel onwaarschijnlijker maakt.

Hoe aanvallers WordPress-gebruikersnamen opsommen

Er zijn verschillende methoden die aanvallers gebruiken om gebruikersnamen op een WordPress-site te ontdekken. Door elke methode te begrijpen weet u waartegen u zich moet beschermen.

• Auteursarchief-URL's: WordPress maakt standaard auteursarchieven aan op /author/gebruikersnaam/. Een aanvaller kan ?author=1, ?author=2, enzovoort bezoeken. WordPress leidt deze om naar de bijbehorende auteursarchief-URL, die de gebruikersnaam in platte tekst bevat. Geautomatiseerde scripts kunnen zeer snel auteur-ID's doorlopen om een complete lijst met gebruikersnamen op te bouwen.
• REST API users-endpoint: De WordPress REST API stelt een /wp-json/wp/v2/users-endpoint bloot dat een JSON-array retourneert van alle gebruikers die berichten hebben gepubliceerd. Dit omvat gebruikersnamen, weergavenamen en gebruikers-ID's. Standaard is geen authenticatie vereist om dit endpoint te benaderen.
• Foutmeldingen bij inloggen: Wanneer u een ongeldige gebruikersnaam invoert op de WordPress-inlogpagina, zegt de foutmelding zoiets als "De gebruikersnaam X is niet geregistreerd." Wanneer u een geldige gebruikersnaam maar een verkeerd wachtwoord invoert, zegt deze "Het door u ingevoerde wachtwoord voor de gebruikersnaam X is onjuist." Dit verschil vertelt de aanvaller of een gebruikersnaam bestaat.
• oEmbed-responsen: WordPress oEmbed-discoverylinks in de paginabron kunnen auteurinformatie onthullen wanneer andere sites proberen uw inhoud in te sluiten.
• XML-RPC: Het xmlrpc.php-endpoint kan worden gebruikt om gebruikersnaam/wachtwoord-combinaties te testen via de methode wp.getUsersBlogs. Hoewel dit meer een brute-force-vector is, bevestigt het geldige gebruikersnamen via verschillende foutresponsen.

Waarom gebruikersopsomming belangrijk is voor beveiliging

Op zichzelf brengt het kennen van een gebruikersnaam uw site niet in gevaar. Maar het maakt al het andere gemakkelijker voor een aanvaller. Beschouw een brute-force-aanval: als de aanvaller zowel de gebruikersnaam als het wachtwoord moet raden, is het aantal mogelijke combinaties enorm. Als hij al weet dat de gebruikersnaam "admin" of "john" is, hoeft hij zich alleen te concentreren op het wachtwoord. Gecombineerd met veelvoorkomende wachtwoordlijsten kan dit binnen enkele minuten in plaats van jaren tot een succesvolle inbreuk leiden.

Bovendien kunnen ontdekte gebruikersnamen worden gebruikt in gerichte phishing-aanvallen. Als een aanvaller weet dat uw beheerdersaccount "sarah.johnson" is, kan hij overtuigender social engineering-e-mails opstellen.

Auteursarchief-opsomming blokkeren

Voeg deze code toe aan het functions.php-bestand van uw thema of een aangepaste plugin. Het onderschept verzoeken met de parameter ?author=N en stuurt deze door naar de homepage in plaats van de gebruikersnaam te onthullen:

/**
 * Block user enumeration via author parameter
 */
function block_author_enumeration() {
    if (is_admin()) return;

    if (isset($_REQUEST['author']) && is_numeric($_REQUEST['author'])) {
        wp_redirect(home_url(), 301);
        exit;
    }
}
add_action('init', 'block_author_enumeration');

Dit handelt de meest voorkomende opsommingsmethode af. De controle is_admin() zorgt ervoor dat backend-functionaliteit niet wordt beïnvloed. De doorverwijzing gebruikt een 301-statuscode, die zoekmachines vertelt hun index bij te werken (voor het geval auteursarchief-URL's eerder zijn geïndexeerd).

De REST API users-endpoint uitschakelen

De volgende code verwijdert het users-endpoint uit de REST API voor bezoekers die niet zijn ingelogd. Geauthenticeerde gebruikers (zoals beheerders en redacteuren) hebben nog steeds toegang, wat de functionaliteit voor de blokkeneditor en andere beheertools behoudt:

/**
 * Remove REST API users endpoint for unauthenticated requests
 */
add_filter('rest_endpoints', function($endpoints) {
    if (!is_user_logged_in()) {
        if (isset($endpoints['/wp/v2/users'])) {
            unset($endpoints['/wp/v2/users']);
        }
        if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
            unset($endpoints['/wp/v2/users/(?P[\d]+)']);
        }
    }
    return $endpoints;
});

Na het toevoegen van deze code zullen niet-geauthenticeerde verzoeken aan /wp-json/wp/v2/users een 404-fout retourneren in plaats van uw gebruikers op te sommen.

Foutmeldingen bij inloggen saneren

WordPress toont verschillende foutmeldingen voor "ongeldige gebruikersnaam" en "verkeerd wachtwoord". Dit onthult of een bepaalde gebruikersnaam op de site bestaat. De oplossing is eenvoudig: retourneer dezelfde generieke melding voor alle inlogmislukkingen:

/**
 * Use a generic login error message
 */
add_filter('login_errors', function() {
    return 'Invalid username or password.';
});

Met deze wijziging kan een aanvaller niet bepalen of een inlogpoging mislukte vanwege een verkeerde gebruikersnaam of een verkeerd wachtwoord. Beide gevallen leveren dezelfde respons op.

oEmbed-discoverylinks verwijderen

WordPress voegt oEmbed-discoverylinks toe in de HTML-head van uw pagina's. Deze links kunnen auteurinformatie onthullen wanneer andere sites proberen uw inhoud in te sluiten. Verwijder ze met een enkele regel:

remove_action('wp_head', 'wp_oembed_add_discovery_links');

Dit beïnvloedt uw mogelijkheid om inhoud van andere sites in te sluiten niet. Het voorkomt alleen dat andere sites automatisch insluitbare inhoud op uw site ontdekken.

Auteursopsomming blokkeren via .htaccess

Als u Apache gebruikt, kunt u een serverniveau-doorverwijzing toevoegen die auteursopsomming blokkeert voordat WordPress zelfs maar wordt geladen. Dit is efficiënter dan een PHP-gebaseerde oplossing omdat geen PHP-verwerking nodig is:

# Block user enumeration via author parameter
RewriteCond %{QUERY_STRING} ^author=\d+ [NC]
RewriteRule .* /? [R=301,L]

Plaats dit in uw .htaccess-bestand voor de WordPress-rewriteregels. Het vangt elk verzoek met een author=-queryparameter die een nummer bevat en stuurt door naar de homepage.

Plugin-gebaseerde oplossingen

Als u liever geen code handmatig toevoegt, handelen verschillende beveiligingsplugins gebruikersopsomming-preventie af:

• Stop User Enumeration: Een gerichte, lichte plugin die specifiek auteursscans en REST API-gebruikerslijsten blokkeert. Doet één ding en doet het goed.
• iThemes Security (Solid Security): Een uitgebreide beveiligingssuite met gebruikersopsommingsbescherming naast functies als tweefactorauthenticatie, bestandswijzigingsdetectie en brute-force-bescherming. De opsommingsblokkering is te vinden onder de sectie "WordPress Tweaks".
• Wordfence: Voornamelijk een firewall en malwarescanner, maar de firewallregels kunnen opsommingspogingen blokkeren. De gratis versie biedt basisbescherming; de premium versie voegt realtime firewallregels toe.
• All In One WP Security: Een gratis, beginnersvriendelijke plugin met een gebruikersopsommingspreventie-optie onder User Accounts > WP Username. Biedt ook een firewall en login-lockdown-functies.

Test opsomming op uw eigen site

Voor en na het implementeren van deze beveiligingen moet u testen of opsomming nog werkt. Zo doet u dat:

• Auteursarchief-test: Open een privébrowservenster en bezoek https://uwsite.nl/?author=1. Als de bescherming werkt, zou u doorgestuurd moeten worden naar de homepage in plaats van een auteursarchiefpagina te zien met de gebruikersnaam in de URL.
• REST API-test: Open https://uwsite.nl/wp-json/wp/v2/users in uw browser zonder ingelogd te zijn. U zou een 404-fout of een lege respons moeten zien, geen lijst van gebruikers met hun gebruikersnamen.
• Inlogpagina-test: Probeer in te loggen met een gebruikersnaam die niet bestaat, en probeer vervolgens met een echte gebruikersnaam maar een verkeerd wachtwoord. Beide moeten dezelfde foutmelding produceren.
• InspectWP-scan: Voer een nieuwe InspectWP-scan van uw site uit. De beveiligingssectie controleert op gebruikersopsommingskwetsbaarheden en geeft aan of uw beveiligingen correct werken.

Aanvullende hardening-tips

Gebruikersopsommingspreventie werkt het best als onderdeel van een bredere beveiligingsstrategie. Overweeg deze aanvullende maatregelen:

• Vermijd "admin" als gebruikersnaam: Als uw beheerdersaccount nog steeds "admin" heet, maak dan een nieuw beheerdersaccount aan met een unieke gebruikersnaam, wijs alle inhoud eraan toe en verwijder vervolgens het oude "admin"-account.
• Gebruik sterke, unieke wachtwoorden: Zelfs als een aanvaller een gebruikersnaam ontdekt, maakt een sterk wachtwoord brute-force-aanvallen onpraktisch. Gebruik een wachtwoordmanager om complexe wachtwoorden te genereren en op te slaan.
• Schakel tweefactorauthenticatie in: 2FA voegt een tweede beschermingslaag toe. Zelfs als zowel de gebruikersnaam als het wachtwoord gecompromitteerd zijn, kan de aanvaller nog steeds niet inloggen zonder de tweede factor.
• Beperk inlogpogingen: Plugins zoals Limit Login Attempts Reloaded of Loginizer kunnen IP-adressen blokkeren na een ingesteld aantal mislukte inlogpogingen.