Hoe controleer ik wat mijn WordPress-site naar buiten laat zien?

Waarom het ertoe doet

Het meeste beveiligingsadvies gaat over schakelaars: zet dit aan, schakel dat uit. Maar een schakelaar vertelt je wat je hebt gevraagd, niet wat er is gebeurd. Een cachelaag kan een oud antwoord serveren. Een CDN-regel kan een bestand blokkeren voordat WordPress het verzoek ooit ziet. Een plugin kan iets weer openzetten dat een andere had gesloten. Het enige eerlijke antwoord op "wat laat mijn site zien?" krijg je door het te vragen zoals een buitenstaander dat zou doen.

Het goede nieuws: de lijst met dingen die het waard zijn om aan de inlogkant te controleren, is kort. Bots zoeken op elke WordPress-site naar hetzelfde handjevol adressen:

Geen daarvan is op zichzelf een ramp. Samen geven ze een bot een lijst met namen en twee deuren om ze op uit te proberen. Weet je welke openstaan, dan kun je ze in de juiste volgorde sluiten: eerst de deuren, dan de namen.

Veelgemaakte fouten

• Testen terwijl je bent ingelogd. WordPress laat ingelogde gebruikers meer zien. Gebruik een privévenster of curl.
• De gecachte pagina testen. Heb je net een instelling gewijzigd, leeg dan eerst je paginacache en CDN-cache, anders zie je het oude antwoord.
• Stoppen bij het eerste groene lampje. Het inlogformulier sluiten terwijl XML-RPC openblijft, is de halve oplossing die we het vaakst zien.
• Een volledige beveiligingsaudit verwachten. Deze checks gaan over de toegangswegen. Ze zeggen niets over malware, gewijzigde bestanden of verouderde plugins.

Zonder plugin

De vijf curl-commando's uit stap 1 zijn de handmatige methode, en het loont om ze te kennen. Lees de resultaten zo:

• HTTP/2 200 op wp-login.php: de standaardlogin is openbaar. 404: hij is verborgen.
• XML-RPC server accepts POST requests only. van xmlrpc.php: het endpoint is actief. Om te zien of inloggen wordt geaccepteerd, zou je een wp.getUsersBlogs-aanroep met een testaccount moeten sturen.
• Een JSON-array van /wp/v2/users met "slug"-velden: gebruikersnamen zijn openbaar. 401 of een lege array: gesloten.
• Location: /author/name/ van ?author=1: een lek. Herhaal met 2, 3 enzovoort om te zien hoeveel gebruikers een bot zou kunnen verzamelen.
• 200 op de gebruikerssitemap: auteurs-URL's worden opgesomd.

Het nadeel is de tijd en de interpretatie. Je moet het na elke wijziging herhalen, en XML-RPC-login goed testen betekent XML met de hand opstellen.

Als er iets misgaat

• De scan zegt "open", maar je hebt het uitgeschakeld. Leeg de pagina- en CDN-cache en scan opnieuw. Staat het nog steeds open, dan overschrijft mogelijk een andere plugin of een serverregel de instelling.
• De scan kan je site niet bereiken. Sommige hosts blokkeren dat een site verzoeken naar zichzelf stuurt (loopback). Vraag je host om loopback-verzoeken toe te staan, of gebruik de curl-methode van buitenaf.
• Er lekt na het dichtzetten nog steeds een gebruikersnaam uit. Controleer het auteursblok van je thema en de auteurssitemap van een eventuele SEO-plugin. Wijzig de weergavenaam van de auteur als het thema die toont.

Met Hushfort

De Oppervlakscan zit in het paneel Oppervlakbeveiliging van Hushfort Security, de gratis WordPress-beveiligingsplugin. Hij meet met echte verzoeken wat je site werkelijk laat zien, net als de handmatige methode, en noemt de gebruikersnamen die hij vindt bij naam. Elke bevinding hoort bij een Hushfort-laag die hem dichtzet:

• XML-RPC-login → Achterdeurslot (Pro)
• REST-gebruikerslijst, auteursscans, sitemap → Gebruikersnaamschild (Pro)
• Standaardlogin → Login verbergen (gratis)

We hebben de Oppervlakscan gebouwd nadat een webwinkel wachtwoordpogingen via XML-RPC bleef ontvangen, terwijl de inlogpagina verborgen was. De instelling zag er goed uit; alleen een echt verzoek liet de open deur zien.