WordPress beveiliging

Bevestig WordPress voordat u gaat testen

VICE controleert het geverifieerde domein op WordPress pagina-, header- en public asset-markeringen voordat gerichte onderzoeken worden uitgevoerd. Hierdoor blijft het resultaat gekoppeld aan waargenomen CMS-gedrag in plaats van aan een geraden technologielabel.

Als WordPress niet kan worden bevestigd, rapporteert de audit een dekkingsbeperking in plaats van een beveiligingsscore of kwetsbaarheid te verzinnen.

Beoordeel de blootstelling aan de publieke identiteit

WordPress kan accountnamen onthullen via auteursomleidingen en het openbare REST-gebruikerseindpunt. VICE registreert het waargenomen gedrag, zodat je het kunt vergelijken met het beoogde publicatiemodel van de site.

• Archiefomleidingen van auteurs die een inlog- of weergavenaam weergeven.
• Openbare reacties van het eindpunt van de REST-gebruikers.
• Bewijsmarkeringen die het geteste pad identificeren zonder gevoelige responsinhoud op te slaan.

Inspecteer XML-RPC, login en cron

Bereikbaarheid alleen is geen bewijs van uitbuiting. Elk gedetecteerd probleem moet het waargenomen sterkere gedrag, het vertrouwen ervan en de aanbevolen controle beschrijven.

• Bereikbaar XML-RPC-gedrag dat de efficiëntie van wachtwoordpogingen kan vergroten.
• Het standaard inlogpad WordPress en het publieke gedrag ervan.
• Openbare HTTP toegang tot het cron-eindpunt WordPress.

Start de gerichte audit

Open WordPress in een geverifieerde domeinwerkruimte en start de scan. De run verschijnt in de centrale auditlijst met dezelfde status en historie als elke beheerde audit.

Problemen waar actie op ondernomen kan worden, worden toegevoegd aan de weergave van gedetecteerde domeinproblemen. WordPress blijft ook beschikbaar tijdens volledige en op maat gemaakte beveiligingsaudits.

Lees de blootstelling in context

Een openbare auteursnaam kan opzettelijk zijn op een publicerende site, terwijl een login-ID die elders wordt hergebruikt meer risico met zich meebrengt. Beoordeel het bewijsmateriaal aan de hand van het accountmodel, de authenticatiecontroles en de operationele vereisten.

Een mislukt verzoek of een onbereikbare site is een dekkingsbeperking. Het is geen kritiek WordPress gedetecteerd probleem.

Repareren en opnieuw testen

Voer de gerichte WordPress-audit opnieuw uit vanuit dezelfde werkruimte en vergelijk de gelijkwaardige dekking voordat u een gedetecteerd probleem als opgelost markeert.

• Beperk de opsomming van openbare gebruikers wanneer de site dit niet nodig heeft.
• Schakel XML-RPC uit wanneer deze niet wordt gebruikt, of bescherm de vereiste methoden met sterke authenticatie en snelheidslimieten.
• Bescherm inlogstromen met snelheidslimieten, sterke inloggegevens en multi-factor authenticatie, indien beschikbaar.
• Geef de voorkeur aan een serverplanner voor WordPress cron wanneer openbare HTTP-triggering niet nodig is.