Webbsäkerhet: en praktisk guide
De flesta webbplatser angrips inte medvetet. De hittas av automatiska skannrar som sveper internet efter kända sårbarheter och svaga lösenord. Det är goda nyheter, för det betyder att grundläggande åtgärder stoppar merparten av angreppen.
Den här guiden går igenom de åtgärderna, ungefär i ordning efter hur mycket risk de tar bort per nedlagd insats.
Åtkomst: där de flesta intrång börjar#
Stulna eller gissade inloggningsuppgifter är det vanligaste sättet små webbplatser faller på — vanligare än någon teknisk sårbarhet.
- Tvåfaktorsautentisering på varje administratörskonto, utan undantag.
- Unika lösenord från en lösenordshanterare; återanvända lösenord läcker någon annanstans och testas här.
- Ta bort konton för personer som slutat och för gamla byråer — detta glöms nästan alltid.
- Ge minsta möjliga behörighet; en redaktör behöver inte vara administratör.
- Begränsa inloggningsförsök och blockera efter upprepade misslyckanden.
- Skydda även det som ligger runtomkring: webbhotell, DNS, domänregistrar och e-post. Att förlora DNS är värre än att förlora webbplatsen.
- Använd SFTP eller SSH-nycklar, aldrig vanlig FTP med lösenord.
Domänregistraren är det konto som oftast lämnas utan tvåfaktor och som orsakar mest skada om det faller.
Uppdateringar och angreppsyta#
Varje installerad programvara är något som måste hållas uppdaterat. Det billigaste säkerhetsarbetet är att ta bort det du inte använder.
| Åtgärd | Varför det räknas |
|---|---|
| CMS-kärnan uppdaterad | Kända sårbarheter skannas inom dagar |
| Tillägg uppdaterade | Vanligaste vägen in på WordPress-webbplatser |
| Ta bort oanvända tillägg | Inaktiverat är inte säkert; koden finns kvar |
| Ta bort oanvända teman | Samma skäl, glöms ännu oftare |
| Stödd PHP-version | Gamla versioner får inga säkerhetsfixar |
| Serverpaket uppdaterade | Ingår hos leverantören vid managerad drift — kontrollera |
| Beroenden i egen kod | Bibliotek åldras också |
Kör uppdateringar i testmiljö och testa sedan formulär och, i en butik, kassaflödet. En uppdatering som tyst bryter ett formulär är ett eget slags fel.
Applikations- och serverskydd#
Åtgärderna som täcker tekniska sårbarheter snarare än åtkomst.
- Validera och sanera all indata på serversidan. Kontroll i webbläsaren är bekvämlighet, inte säkerhet.
- Använd förberedda frågor vid all databasåtkomst — det stänger SQL-injektion.
- Escapa utdata vid visning för att förhindra skriptning över webbplatser.
- HTTPS överallt, med HSTS och ett automatiskt förnyat certifikat.
- Sätt säkerhetsheaders: Content-Security-Policy, X-Content-Type-Options, Referrer-Policy.
- Begränsa filuppladdningar efter typ och storlek, och lagra dem utanför webbroten.
- Stäng av felvisning i produktion; felmeddelanden berättar för angripare vad som körs.
- Överväg en webbapplikationsbrandvägg vid ett CMS med många tillägg.
Säkerhetskopior och återhämtning efter intrång#
Säkerheten fallerar ibland. Vad som händer då beror helt på vad du förberett i förväg.
- Lagra kopior utanför servern. En kopia på samma maskin krypteras eller raderas med resten.
- Behåll flera generationer. Upptäcks ett intrång först efter två veckor är gårdagens kopia också smittad.
- Testa återställning kvartalsvis. Det är steget som oftast saknas.
- Vid intrång: ta ner webbplatsen eller sätt den i underhållsläge innan du gör något annat.
- Byt varje lösenord — CMS, webbhotell, databas, FTP, DNS — innan du återställer.
- Återställ från en kopia före intrånget, och uppdatera allt innan du går live igen.
- Ta reda på hur de tog sig in. Att återställa utan att hitta orsaken betyder att det händer igen.
Vid en incident med personuppgifter gäller anmälningsplikt med korta tidsfrister. Vet i förväg vem som bedömer det, inte under incidenten.
Vanliga frågor
Är WordPress osäkert?
Kärnan är någorlunda välskött; risken ligger nästan alltid i tillägg, teman och svaga administratörslösenord. En WordPress-webbplats med tvåfaktor, få tillägg och aktuella uppdateringar är helt okej. En webbplats med fyrtio tillägg där hälften inte uppdaterats på två år är en tidsfråga.
Behöver jag ett säkerhetstillägg?
De är nyttiga för inloggningsbegränsning, filbevakning och larm, men de ersätter inget i listan ovan. Ett säkerhetstillägg på en webbplats med föråldrade tillägg och ett delat administratörslösenord löser inte det verkliga problemet. Se det som en brandvarnare, inte som brandsäkert byggande.
Vad gör jag om min webbplats hackas?
Ta ner den, byt varje lösenord inklusive webbhotell och DNS, och återställ sedan från en ren kopia före intrånget. Uppdatera allt innan du går live igen, och ta reda på hur de kom in — annars upprepas det inom veckor. Berörs personuppgifter gäller anmälningsplikt med korta tidsfrister.
Skyddar HTTPS min webbplats mot hackare?
Nej, och det är ett vanligt missförstånd. HTTPS krypterar trafiken mellan besökare och server, vilket förhindrar avlyssning och manipulation på vägen. Det gör inget mot svaga lösenord, föråldrade tillägg eller SQL-injektion. Det är nödvändigt och fullständigt otillräckligt.
webbsäkerhetförhindra hackningwordpress säkerhetssl-certifikatsäkerhetsheadershackad webbplats
