Topp 5 säkerhetskryphål i WordPress-installationer

av

Din WordPress-installation kan vara så säker eller osäker som du vill. Lär dig vilka fem saker som är viktigast när det kommer till säkerhet.

Oro och klagomål om WordPress-säkerhet är inget nytt.

Om du behöver ett CMS och råkar konsultera en tjänsteleverantör som inte är inblandad i WordPress, är säkerhet den största nackdelen du kommer att höra talas om. Betyder det att alla borde släppa WordPress och byta till statiska webbplatsgeneratorer eller ett huvudlöst CMS?

Nej, för precis som varje sanning i livet har även denna många sidor.

Är WordPress mycket osäkert?

Låt oss ta en titt på några enorma webbplatser som byggdes på WordPress:

  • TechCrunch
  • New Yorkern
  • BBC America
  • Bloomberg
  • MTV News
  • PlayStation-bloggen

Så vad gör att dessa företag – med absurt djupa fickor och en häpnadsväckande arbetsstyrka – inte byter från WordPress? Om du tror att svaret är äldre kod, tänk om: för dessa namn är datasäkerhet och offentlig image oändligt mycket viktigare än en enkel migrering som kommer att kosta (jag uppskattar) mindre än $200 000.

Visst vet deras ingenjörer vad de gör och ser inga grundläggande, olösliga säkerhetsproblem med WordPress?

Till och med jag har turen att hantera en WordPress-installation som ser 3,5-4 miljoner besökare i månaden. Det totala antalet säkerhetsintrång under de senaste åtta åren? Noll!

Så . . . är WordPress säkert?

Jag är ledsen om det verkar som att trolling, men här är mitt svar:

Jag säger det för att det, som alla sanningar i livet, är komplicerat. För att komma fram till ett legitimt svar måste vi först förstå att WordPress (eller något förbyggt CMS, för den delen) inte är som ett skåp du sticker någonstans permanent och blir klar med det.

Det är en komplex mjukvara med många beroenden:

  • PHP, vilket är språket det är byggt med
  • En offentligt synlig dator som är värd för installationen
  • Webbservern som används för att hantera besökare (Apache, Nginx, etc.)
  • Databasen som används (MySQL/MariaDB)
  • Teman (paket med PHP-, CS- och JS-filer)
  • Plugins (paket med PHP-, CS- och JS-filer)
  • Och många fler, beroende på hur mycket din installation syftar till att åstadkomma

Med andra ord kommer ett säkerhetsbrott i någon av dessa sömmar att kallas ett WordPress-brott.

Om serverns root-lösenord var admin123 och det kompromitterades, är det WordPress-säkerhetsfel?

Om PHP-versionen hade en säkerhetsrisk, eller om den nya plugin du köpte och installerade innehöll ett påfallande säkerhetshål; och så vidare. För att sammanfatta: Ett undersystem misslyckas, och det är ett säkerhetsfel i WordPress.

För övrigt, låt inte detta ge dig intrycket av att PHP, MySQL och Apache inte är säkra. Varje mjukvara har sårbarheter, vars antal är häpnadsväckande i fallet med öppen källkod (eftersom den är tillgänglig för alla att se och analysera).

Sa någon ”säker”? 😛

Det vi lär oss av all denna övning är detta:

Ingenting är säkert eller osäkert i sig. Det är de olika komponenterna som används som bildar länkarna i kedjan, kedjan är naturligtvis lika stark som den svagaste av dem. Historiskt sett var WordPress-etiketten ”inte säker” en kombination av gamla PHP-versioner, delad hosting och tillägg av plugins/teman från opålitliga källor.

Samtidigt gör några ganska vanliga förbiseenden din WordPress-installation sårbar för dem som vet hur man utnyttjar dem och är beslutsamma. Och det är vad det här inlägget handlar om. Så utan vidare (och cirkulära argument), låt oss sätta igång.

De bästa kryphålen i WordPress som hackare kan utnyttja

WordPress-tabellprefixet

Den berömda 5-minutersinstallationen är det bästa som händer med WordPress, men som alla installationsguider gör det oss lata och lämnar saker som standard.

Detta betyder att standardprefixet för dina WordPress-tabeller är wp_, vilket resulterar i tabellnamn som alla kan gissa:

  • wp-användare
  • wp-alternativ
  • wp-inlägg

Tänk nu på en attack som kallas SQL Injection, där skadliga databasfrågor sätts in och görs för att köras inuti WordPress (observera att detta inte på något sätt är en WordPress/PHP-exklusiv attack).

Även om WordPress har inbyggda mekanismer för att hantera dessa typer av attacker, kan ingen garantera att det inte kommer att hända.

Så om angriparen på något sätt, på något sätt, lyckas köra en fråga som DROP TABLE wp_users; SLÄPP TABELL wp_posts;, alla dina konton, profiler och inlägg kommer att raderas på ett ögonblick utan chans till återställning (såvida du inte har ett säkerhetskopieringsschema på plats, men även då är du skyldig att förlora data sedan den senaste säkerhetskopieringen ).

Att bara ändra prefixet under installationen är en stor sak (vilket kräver ingen ansträngning).

Något slumpmässigt som sdg21g34_ rekommenderas eftersom det är nonsens och svårt att gissa (ju längre prefix, desto bättre). Det bästa är att detta prefix inte behöver vara minnesvärt; prefixet är något WordPress kommer att spara, och du behöver aldrig mer oroa dig för det (prefix som du inte oroar dig för standardprefixet wp_!).

Standardinloggnings-URL

Hur vet du att en webbplats körs på WordPress? Ett av de kontrollanta tecknen är att du ser WordPress-inloggningssidan när du lägger till ”/wp-login.php” till webbadressen.

Som ett exempel, låt oss ta min webbplats (http://ankushthakur.com). Finns det på WordPress? Nåväl, fortsätt och lägg till inloggningsdelen. Om du känner dig för lat händer det här:

¯_(ツ)_/¯

WordPress, eller hur?

När så mycket är känt kan angriparen gnugga sina händer i glädje och börja använda otäcka trick från sin Bag-O’-Doom på alfabetisk basis. Stackars mig!

Lösningen är att ändra standardinloggningsadressen och ge den endast till de personer som är betrodda.

Den här webbplatsen finns till exempel också på WordPress, men om du besöker http://adminvista.com.com/wp-login.php får du bara en djup besvikelse. Inloggningsadressen är dold och är endast känd för administratörerna?

Att ändra inloggningsadressen är inte heller raketvetenskap. Ta bara tag i det här plugin.

Grattis, du har precis lagt till ytterligare ett lager av frustrerande säkerhet mot brute force-attacker.

PHP och webbserverversionen

Vi har redan diskuterat att varje mjukvara som någonsin skrivits (och som skrivs) är full av buggar som väntar på att bli utnyttjade.

Detsamma gäller för PHP.

Även om du använder den senaste versionen av PHP kan du inte vara säker på vilka sårbarheter som finns och kan upptäckas över en natt. Lösningen är att dölja en viss rubrik som skickas av din webbserver (aldrig hört talas om rubriker? läs detta!) när en webbläsare ansluter till den: x-powered-by.

Så här ser det ut om du kollar utvecklingsverktygen i din favoritwebbläsare:

Som vi kan se här berättar webbplatsen att den körs på Apache 2.4 och använder PHP version 5.4.16.

Nu är det redan massor av information vi förmedlar utan anledning, vilket hjälper angriparen att begränsa sitt val av verktyg.

Dessa (och liknande) rubriker måste döljas.

Lyckligtvis kan det göras snabbt; tyvärr behövs sofistikerad teknisk kunskap eftersom du måste dyka ner i systemets magkänsla och bråka med viktiga filer. Därför är mitt råd att be din webbhotellsleverantör att göra detta åt dig; om de inte ser om en konsult kan få det gjort, men det beror till stor del på din webbplatsvärd om deras installation har sådana möjligheter eller inte.

Om det inte fungerar kan det vara dags att byta värdleverantör eller flytta till en VPS och anlita en konsult för säkerhets- och administrationsproblem.

Är det värt det? Det kan bara du bestämma. 🙂

Åh, och om du vill nörda på säkerhetsrubriker, här är din fix!

Antal inloggningsförsök

Ett av de äldsta knepen i hackarens handbok är den sk Ordbok Attack.

Tanken är att du försöker ett löjligt stort antal (miljoner, om möjligt) kombinationer för ett lösenord om inte en av dem lyckas. Eftersom datorer är blixtsnabba på vad de gör, är ett sånt dumt upplägg vettigt och kan ge resultat inom rimlig tid.

Ett vanligt (och extremt effektivt) försvar har varit att lägga till en fördröjning innan felet visas. Detta gör att mottagaren väntar, vilket innebär att om det är ett skript som använts av en hackare, kommer det att ta för lång tid att avsluta. Det är anledningen till att din dator eller favoritapp studsar lite och sedan säger ”Hoppsan, fel lösenord!”.

Hur som helst, poängen är att du bör begränsa antalet inloggningsförsök för din WordPress-webbplats.

Utöver ett visst antal försök (säg fem), bör kontot låsas och bör endast kunna återställas via kontoinnehavarens e-post.

Tack och lov är att få detta gjort en cakewalk om du stöter på en trevlig plugin.

HTTP kontra HTTPS

SSL-certifikatet som din leverantör har tjatat om är viktigare än du kanske tror.

Det är inte bara ett rykteverktyg för att visa en grön låsikon i webbläsaren som säger ”Säker”; snarare att få ett SSL-certifikat installerat och tvinga alla webbadresser att fungera på ”https” är ensamt tillräckligt för att ta din webbplats från att vara en öppen bok till en kryptisk rullning.

Om du inte förstår hur detta händer, läs om något som kallas a man-i-mitten attack.

Ett annat sätt att fånga upp trafiken som strömmar från din dator till servern är paketsniffning, som är en passiv form av datainsamling och som inte ens behöver anstränga sig för att placera sig i mitten.

För webbplatser som körs över vanlig ”HTTP” visas den person som avlyssnar nätverkstrafiken, dina lösenord och kreditkortsnummer tydlig, vanlig text.

Källa: comparitech.com

Skrämmande? Mycket!

Men när du väl har installerat ett SSL-certifikat och alla webbadresser konverteras till ”https” visas den här känsliga informationen som trams som bara servern kan dekryptera. Med andra ord, svettas inte dessa få dollar om året. 🙂

Slutsats

Kommer att få dessa fem saker under kontroll att säkra din webbplats snyggt?

Nej inte alls. Som otaliga säkerhetsartiklar säger, du är aldrig 100% säker, men det är möjligt att eliminera en stor klass av dessa problem med rimlig ansträngning. Du kan överväga att använda SUCURI cloud WAF för att skydda dina webbplatser holistiskt.