Din installation av WordPress kan vara så säker eller osäker som du önskar. Upptäck de fem viktigaste aspekterna att tänka på gällande säkerhet.
Oron och klagomålen om WordPress säkerhet är ingenting nytt.
Om du är i behov av ett CMS och frågar en tjänsteleverantör som inte sysslar med WordPress, är säkerhet det största problemet de kommer att ta upp. Borde alla då överge WordPress och byta till statiska sidgeneratorer eller ett huvudlöst CMS?
Absolut inte, liksom alla sanningar i livet så har även denna många bottnar.
Är WordPress verkligen så osäkert?
Låt oss se på några stora webbplatser som är skapade med WordPress:
- TechCrunch
- The New Yorker
- BBC America
- Bloomberg
- MTV News
- PlayStation Blog
Så varför byter inte dessa företag, som har stora resurser och en enorm personal, från WordPress? Om du tror att orsaken är gammal kod, tänk om: för de här företagen är datasäkerhet och deras offentliga anseende mycket viktigare än en enkel migrering som skulle kosta (min uppskattning) mindre än 2 miljoner kronor.
Deras utvecklare vet förmodligen vad de gör och ser inga grundläggande, olösliga säkerhetsproblem med WordPress?
Även jag har turen att förvalta en WordPress-installation som får 3,5-4 miljoner besökare varje månad. Det totala antalet säkerhetsincidenter under de senaste åtta åren? Noll!
Så… är WordPress säkert?
Jag är ledsen om det låter som att jag driver med dig, men här är mitt svar:
Jag svarar så här eftersom det, precis som alla sanningar i livet, är komplicerat. För att komma fram till ett bra svar behöver vi först inse att WordPress (eller vilket CMS som helst) inte är som en hylla som du ställer upp och sedan är klar med den.
Det är en komplex mjukvara med många beroenden:
- PHP, språket det är skapat med
- En offentligt tillgänglig dator där installationen finns
- Webbservern som används för att hantera besökare (Apache, Nginx, osv.)
- Databasen som används (MySQL/MariaDB)
- Teman (paket med PHP-, CS- och JS-filer)
- Tillägg (paket med PHP-, CS- och JS-filer)
- Och mycket mer, beroende på hur mycket din installation ska kunna göra
Med andra ord, en säkerhetsbrist i någon av dessa delar kommer att kallas en WordPress-brist.
Om serverns huvudlösenord var admin123 och det hackades, är det då WordPress säkerhetsfel?
Om PHP-versionen hade en säkerhetslucka, eller om det nya tillägget du köpte och installerade hade ett stort säkerhetshål, och så vidare. Kort sagt: Om ett delsystem misslyckas, är det ett säkerhetsfel i WordPress.
Förresten, låt inte det här ge dig intrycket att PHP, MySQL och Apache inte är säkra. All mjukvara har sårbarheter, vars antal är ganska högt när det gäller öppen källkod (eftersom den är tillgänglig för alla att se och granska).
Sa någon ”säker”? 😛
Det vi lär oss av det här är:
Ingenting är säkert eller osäkert i sig. Det är de olika komponenterna som tillsammans bildar länkarna i kedjan, och kedjan är såklart lika stark som den svagaste länken. Tidigare var etiketten ”inte säker” för WordPress en blandning av gamla PHP-versioner, delad hosting och tillägg/teman från osäkra källor.
Samtidigt gör ett par vanliga misstag din WordPress-installation sårbar för dem som vet hur man utnyttjar dem. Och det är det här inlägget handlar om. Så, utan mer prat, låt oss börja.
De största kryphålen i WordPress som hackare kan utnyttja
WordPress tabellprefix
Den välkända 5-minutersinstallationen är fantastisk med WordPress, men som med alla installationsguider gör den oss lata och lämnar saker som standard.
Det innebär att standardprefixet för dina WordPress-tabeller är wp_, vilket ger tabellnamn som vem som helst kan gissa:
- wp_användare
- wp_alternativ
- wp_inlägg
Tänk dig en attack som kallas SQL Injection, där skadliga databasfrågor läggs in och körs inuti WordPress (observera att det här inte är unikt för WordPress/PHP på något sätt).
Även om WordPress har inbyggda mekanismer för att hantera den här typen av attacker, finns det ingen garanti för att det inte kan hända.
Så om angriparen lyckas köra en fråga som DROP TABLE wp_users; DROP TABLE wp_posts; kommer alla dina konton, profiler och inlägg att raderas på ett ögonblick, utan möjlighet till återställning (om du inte har en säkerhetskopieringsplan, men även då förlorar du data från den senaste säkerhetskopieringen).
Att bara ändra prefixet under installationen är ett stort steg (som inte kräver någon ansträngning).
Något slumpmässigt som sdg21g34_ rekommenderas eftersom det är meningslöst och svårt att gissa (ju längre prefix, desto bättre). Det bästa är att du inte behöver komma ihåg det här prefixet; WordPress kommer att spara det, och du behöver inte bekymra dig över det mer (allt utom standardprefixet wp_!).
Standardinloggningsadress
Hur vet man om en webbplats använder WordPress? En av de tydliga tecknen är att du ser WordPress inloggningssida när du lägger till ”/wp-login.php” till webbadressen.
Låt oss ta min webbplats som exempel (http://ankushthakur.com). Använder den WordPress? Jodå, lägg till inloggningsdelen. Om du är lat, ser det ut så här:
¯_(ツ)_/¯
WordPress, eller hur?
När så mycket är känt, kan angriparen gnugga händerna av glädje och börja använda otäcka trick från sin verktygslåda. Usch!
Lösningen är att ändra standardinloggningsadressen och endast ge den till de personer som du litar på.
Den här webbplatsen använder också WordPress, men om du går till http://adminvista.com/wp-login.php blir du bara besviken. Inloggningsadressen är dold och är endast känd för administratörerna.
Att ändra inloggningsadressen är inte heller raketforskning. Skaffa det här tillägget.
Grattis, du har precis lagt till ännu ett lager av säkerhet mot brute force-attacker.
PHP och webbserverversionen
Vi har redan pratat om att varje program som någonsin har skrivits (och som skrivs) är fullt av buggar som väntar på att utnyttjas.
Samma sak 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 från en dag till nästa. Lösningen är att dölja en viss rubrik som skickas av din webbserver (aldrig hört talas om rubriker? läs det här!) när en webbläsare ansluter till den: x-powered-by.
Så här ser det ut om du kollar utvecklarverktygen i din webbläsare:
Som vi ser här berättar webbplatsen att den körs på Apache 2.4 och använder PHP version 5.4.16.
Det är redan massor av information som vi ger ut utan anledning, vilket hjälper angriparen att begränsa sina val av verktyg.
Dessa (och liknande) rubriker måste döljas.
Det är enkelt gjort, men tyvärr krävs teknisk kunskap eftersom du måste ner i systemets kärna och greja med viktiga filer. Därför är mitt råd att be din webbhotellsleverantör att fixa det här; om de inte kan, kanske en konsult kan hjälpa till, men det beror på din webbhotellsleverantör om deras installation har den möjligheten.
Om det inte fungerar kan det vara dags att byta leverantör eller flytta till en VPS och anlita en konsult för säkerhets- och administrationsfrågor.
Är det värt det? Det får du avgöra. 🙂
Och om du är intresserad av att läsa mer om säkerhetsrubriker, varsågod!
Antal inloggningsförsök
En av de äldsta metoderna i en hackares verktygslåda är en ordboksattack.
Idén är att du testar ett otroligt antal (miljoner om möjligt) kombinationer för ett lösenord tills du hittar rätt. Eftersom datorer är otroligt snabba på det de gör, är en sån här dum idé användbar och kan ge resultat inom en rimlig tid.
Ett vanligt (och väldigt effektivt) försvar har varit att lägga till en fördröjning innan felet visas. Det tvingar mottagaren att vänta, vilket innebär att om det är ett skript som används av en hackare kommer det att ta alldeles för lång tid att slutföra. Det är därför din dator eller app studsar lite och sedan säger ”Oj, fel lösenord!”.
Hur som helst, poängen är att du bör begränsa antalet inloggningsförsök för din WordPress-webbplats.
Efter ett visst antal försök (säg fem) bör kontot låsas och bara kunna återställas via kontoinnehavarens e-post.
Tack och lov är det enkelt att fixa det här om du använder ett bra tillägg.
HTTP kontra HTTPS
SSL-certifikatet som din leverantör har pratat om är viktigare än du kanske tror.
Det är inte bara ett verktyg för att visa en grön låsikon i webbläsaren som säger ”Säker”; att installera ett SSL-certifikat och tvinga alla webbadresser att fungera på ”https” är tillräckligt för att göra din webbplats från en öppen bok till en krypterad skrift.
Om du inte förstår hur det här fungerar, läs om något som kallas man-i-mitten-attack.
Ett annat sätt att fånga upp trafiken som går från din dator till servern är genom paketsniffning, vilket är ett passivt sätt att samla in data och som inte kräver att man placerar sig i mitten.
För webbplatser som använder vanligt ”HTTP” visas din information som lösenord och kreditkortsnummer i tydlig, vanlig text för den som fångar upp nätverkstrafiken.
Källa: comparitech.com
Läskigt, eller hur? Väldigt!
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 nonsens som bara servern kan avkoda. Med andra ord, bekymra dig inte för de där extra kronorna om året. 🙂
Slutsats
Kommer du att vara säker om du fixar de här fem sakerna?
Inte alls. Som otaliga säkerhetsartiklar säger är du aldrig 100 % säker, men det är möjligt att bli av med en stor del av de här problemen med en rimlig ansträngning. Du kan överväga att använda SUCURI cloud WAF för att skydda dina webbplatser på ett omfattande sätt.