Grundläggande webbplatssäkerhet: SSL, backuper och de vanligaste attackvägarna

Bokningssajten för ett litet bageri fick omkring 40 besökare om dagen. Ägaren tänkte att ingen skulle bry sig om att attackera den – det fanns ingen kunddatabas att stjäla, ingen betallösning, inget som skrek "mål". Sex veckor efter lanseringen visade det sig att sajten i det tysta spred skadlig kod till besökarna och hade svartlistats av Google Safe Browsing. Ingen hade "hackat" just det här företaget. En bot hade skannat miljontals WordPress-installationer efter en känd sårbarhet i ett plugin, hittat just den här sajten och lagt in sin nyttolast. Ägaren dök aldrig upp som en person på någons radar – sajten dök upp som en träff i en skanning.

Det är den delen som är lätt att missa när man driver en webbplats för ett litet företag: man blir inte utvald, man blir avläst. Automatiserade attackverktyg bryr sig inte om hur stort företaget är, hur mycket trafik sajten får eller om man själv känner sig som ett "riktigt mål". De genomsöker hela den offentliga webben efter specifika, kända svagheter – en föråldrad pluginversion, ett standardanvändarnamn för admin, en osäkrad kärnfil i CMS:et – och utnyttjar det de hittar, urskillningslöst. På sätt och vis är småföretags webbplatser lättare mål än stora företags, just för att de är sämre skyddade: inget säkerhetsteam, ingen övervakning, ingen budgetpost för det och ofta ingen som kollar läget förrän något går synligt sönder.

Den här artikeln går igenom grunderna i webbplatssäkerhet för småföretag: vad SSL faktiskt skyddar, vilka attackvägar som oftast drabbar mindre sajter, hur man säkerhetskopierar på ett sätt som verkligen räddar en i krislägen, och hur en rimlig baslinje för säkerhet ser ut. Inget av detta kräver en budget i företagsklass. Det mesta handlar om disciplinerade grunder, tillämpade konsekvent.

SSL/HTTPS: vad det faktiskt skyddar

SSL (numera tekniskt sett TLS, men "SSL" har fastnat som vardagsterm) är krypteringslagret bakom hänglåsikonen i webbläsarens adressfält och "https://" i början av en URL. Det gör två specifika saker, och det är värt att vara precis med vilka:

• Krypterar data under överföring. Allt som skickas mellan en besökares webbläsare och din server – formulär, inloggningsuppgifter, sidinnehåll – blandas så att det inte går att läsa eller manipulera för någon som avlyssnar anslutningen, till exempel på öppet wifi.
• Verifierar sajtens identitet. Ett giltigt certifikat bekräftar att besökaren faktiskt pratar med din server, inte med någon som sitter emellan och utger sig för att vara den (en "man-in-the-middle"-attack).

Det SSL inte gör är att skydda servern mot intrång, förhindra skadlig kod eller säkra databasen. Det är ett lager, inte ett helt säkerhetssystem. Men det är lagret som förr var valfritt och numera inte är det. För några år sedan var SSL något man la till för e-handelssajter som hanterade kortuppgifter. I dag flaggar webbläsare aktivt varje sajt utan HTTPS som "Ej säker" direkt i adressfältet – en varningsetikett som syns för varje besökare innan de ens hunnit läsa en rad innehåll. Google har dessutom bekräftat HTTPS som en rankingsignal, och verktyg för PageSpeed och Core Web Vitals utgår i allt högre grad från en säker anslutning som baslinje. Att driva en sajt utan SSL kostar i dag både besökarnas förtroende och sökbarheten samtidigt – för en åtgärd som normalt är gratis och automatiserad (Let's Encrypt-certifikat som förnyas automatiskt hos de flesta moderna webbhotell) och tar några minuter att sätta upp. Det finns inte längre någon bra anledning att hoppa över det, oavsett sajt, även en utan formulär eller e-handel.

Attackvägarna som faktiskt drabbar småföretags webbplatser

"Hackad" täcker ett brett spann av scenarier, men för småföretags webbplatser går de allra flesta incidenter tillbaka till en kort lista av kända, väldokumenterade attackvägar. Att förstå dem är det mesta av jobbet, för det gör "säkerhet" till en konkret, hanterbar checklista i stället för en diffus oro.

Föråldrad CMS-kärna och sårbara plugin

Det här är den absolut vanligaste orsaken till att småföretags sajter komprometteras, och den går nästan alltid att förebygga. WordPress driver ungefär 40 procent av webben, vilket gör plattformen – och dess plugin-ekosystem – till ett ständigt mål för sårbarhetsforskning, både seriös och illasinnad. När en säkerhetsbrist upptäcks i ett populärt plugin offentliggörs den ofta (inte sällan tillsammans med en patch), och inom några dagar söker automatiserade skannrar av hela webben efter sajter som fortfarande kör den sårbara versionen. Om ett plugin, tema eller CMS-kärnan inte har uppdaterats är sårbarheten offentligt känd, och ofta är angreppssättet lika offentligt. Det här är ingen sofistikerad, riktad attack – det är en bot som kontrollerar ett versionsnummer.

Svaga eller återanvända admin-lösenord

Credential stuffing – att testa användarnamn och lösenord som läckt från andra intrång mot din inloggningssida – fungerar förvånansvärt ofta, eftersom folk återanvänder lösenord mellan tjänster. Ett admin-lösenord som också använts på något helt orelaterat forum eller en app som drabbades av ett intrång för flera år sedan är en levande risk i dag, tyst, tills någon testar det mot din sajt.

Brute force mot inloggningen

Näraliggande men distinkt: automatiserade verktyg testar helt enkelt stora volymer av vanliga lösenord och användarnamn mot ett inloggningsformulär, utan att behöva någon lista med läckta uppgifter. Standardanvändarnamn som "admin" i kombination med en inloggningssida som aldrig låser sig efter misslyckade försök gör det här trivialt enkelt att köra i stor skala – och det körs mot i princip varenda offentligt känd CMS-inloggning på webben, kontinuerligt.

SQL-injektion och cross-site scripting (XSS)

De här spelar störst roll för skräddarsydda sajter och applikationer snarare än standardinstallationer av ett CMS (även om dåligt skrivna plugin också kan introducera dem). SQL-injektion utnyttjar bristfälligt validerade databasfrågor för att låta en angripare läsa, ändra eller radera data som denne inte ska ha åtkomst till. XSS injicerar skadliga skript i sidor som visas för andra användare – ofta via ett kommentarsfält, en sökruta eller vilket inmatningsfält som helst som inte är korrekt kodat innan det visas i webbläsaren igen. Båda är väldokumenterade sårbarhetsklasser som funnits i decennier, med etablerade sätt att förebygga dem (parametriserade frågor, indatavalidering, utdatakodning) – de lever kvar mest i kod som aldrig granskats med säkerhet i åtanke.

Skadliga filuppladdningar

Varje funktion som låter användare eller administratörer ladda upp filer – bilduppladdning, dokumentinlämning, CV-formulär – är en potentiell attackväg om servern inte strikt validerar vad som faktiskt laddas upp. En angripare som lyckas få upp en skriptfil på servern, förklädd till en bild eller ett dokument, och får servern att köra den, får i praktiken ett fotfäste inne i sajten.

Komprometterade tredjepartsplugin och -skript

Alla intrång börjar inte med den egna konfigurationen. Analysverktyg, chattwidgetar, annonsskript och plugin hämtar kod från tredjepartskällor. Om en av dessa tredje parter komprometteras uppströms kan den skadliga koden flyta ut till varenda sajt som använder den – ett problem i leverantörskedjan snarare än en direkt attack mot just din verksamhet. Det är ett bra argument för att hålla antalet tredjepartsskript och plugin på en sajt så lågt som det verkligen behöver vara.

Backuper som faktiskt fungerar, inte bara antas fungera

Var och en av attackvägarna ovan kan i värsta fall sluta med en sajt som klottras ner, raderas eller hålls som gisslan mot en lösensumma. Då är den enda faktorn som avgör om det blir en jobbig eftermiddag eller en företagskris huruvida det finns en ren, fungerande backup. Och ordet "fungerande" gör ett rejält jobb i den meningen, för ett förvånansvärt stort antal "vi har backuper"-upplägg visar sig inte fungera när de väl behövs.

En backupstrategi som verkligen skyddar dig har fyra egenskaper:

• Automatiserad. Om den bygger på att någon kommer ihåg att köra den manuellt kommer det förr eller senare inte att hända – vanligtvis precis innan den behövs.
• Regelbunden. Frekvensen bör matcha hur ofta innehåll och data förändras. En statisk broschyrsajt klarar sig ofta med veckovisa backuper; en e-handelsbutik som tar emot beställningar dagligen behöver minst dagliga, helst tätare, för orderdatabasen.
• Lagrad utanför servern. En backup som ligger på samma server som den skarpa sajten är ingen riktig backup – om den servern komprometteras, raderas eller drabbas av driftstopp hos webbhotellet försvinner backupen med den. Extern lagring (en separat molntjänst, ett helt annat infrastrukturkonto) är det som gör en backup faktiskt motståndskraftig.
• Testad, inte antagen. Det här är steget nästan alla hoppar över, och det som betyder mest. Att en backupfil finns är inte samma sak som en backup som återställs felfritt. Databasexporter kan vara ofullständiga, filbackuper kan missa mappar, återställningsskript kan misslyckas tyst. Det enda sättet att veta att en backup verkligen fungerar är att regelbundet göra en riktig teståterställning – helst till en stagingmiljö – och bekräfta att resultatet är en fullt fungerande sajt, inte bara en mapp med filer som ser rätt ut.

Vi har sett precis det här scenariot spela ut i praktiken: en företagare upptäcker ett intrång, försöker återställa från backup och upptäcker att backuprutinen tyst hade misslyckats i flera månader på grund av en ändrad API-nyckel som ingen roterat i backupkonfigurationen. Backuperna såg fina ut i en dashboard som bara kollade om jobbet hade körts, inte om det gick att återställa från det. En kvartalsvis teståterställning hade fångat felet redan första veckan.

En praktisk baslinje-checklista för säkerhet

Inget av det här kräver specialistkompetens inom säkerhet. Det handlar om disciplin, tillämpad konsekvent, och det mesta går att sätta upp en gång och sedan sköta som rutin.

• Starka, unika admin-lösenord plus tvåfaktorsautentisering. En lösenordshanterare tar bort ursäkten för återanvändning; 2FA gör att ett läckt eller gissat lösenord ensamt inte räcker för att komma in.
• Håll mjukvaran uppdaterad. CMS-kärna, teman och plugin – enligt ett bestämt schema, inte "när någon kommer ihåg det". Det här stänger den enskilt största attackvägen som nämns ovan.
• En webbapplikationsbrandvägg (WAF). Filtrerar bort skadlig trafik (kända angreppsmönster, dåliga bottar, vanliga injektionsförsök) innan den når sajten. Många webbhotell och CDN-leverantörer erbjuder det här som en inbyggd eller lågkostnadsfunktion.
• Begränsa antalet inloggningsförsök. Lås eller strypa hastigheten efter ett fåtal misslyckade inloggningar. Det här enskilt neutraliserar de flesta brute force-försök.
• Minimalt med plugin. Varje plugin är en extra attackyta och ytterligare en sak som måste uppdateras. Granska regelbundet och ta bort det som inte aktivt gör nytta.
• Regelbundna säkerhetsskanningar. Automatiserad skanning efter skadlig kod och sårbarheter fångar problem tidigt – ofta innan de syns för besökare eller sökmotorer, vilket spelar roll eftersom Google tenderar att svartlista en komprometterad sajt snabbt, medan det tar betydligt längre tid att bli av med listningen igen.

Det här är precis den typen av lista som är lätt att skriva ner och svår att hålla aktuell utan att någon faktiskt äger frågan. Vi har gått igenom varför löpande uppmärksamhet betyder mer än en engångsinsats i vår artikel om webbplatsunderhåll som en försäkring för verksamheten, som ser på säkerhet som en del av en bredare bild av underhåll – den här artikeln är den djupare genomgången av just säkerhetsdelen.

Det här bör du göra under den första timmen om du misstänker ett intrång

Om något ser fel ut – okända adminanvändare, oväntade filer, en varning från Google Safe Browsing, besökare som rapporterar konstiga omdirigeringar, en nedklottrad sida – betyder den första timmen mer än något annat. Panik och improvisation tenderar att göra saken värre; en kort, lugn sekvens av åtgärder tenderar att begränsa skadan.

1. Ta sajten offline eller sätt den i underhållsläge om det går snabbt, för att stoppa vidare skada eller spridning till besökare. Går det inte att ta ner sajten helt, stäng åtminstone av publika filuppladdningar och alla uppenbart exponerade formulär.
2. Byt alla admin-lösenord omedelbart – CMS-admin, kontrollpanel hos webbhotellet, FTP/SFTP, databas – från en enhet du är säker på är ren. Utgå från att de gamla lösenorden är komprometterade.
3. Säkra bevis innan du städar upp något. Kopiera misstänkta filer, notera tidsstämplar, kontrollera serverns åtkomstloggar efter ovanlig aktivitet. Det spelar roll både för att förstå hur angriparen tog sig in (så att just den dörren kan stängas) och, om det behövs, för att anmäla till webbhotellet eller berörda myndigheter.
4. Kontrollera backupläget innan du gör något som inte går att ångra. Bekräfta att det finns en ren backup från innan intrånget och ungefär hur långt tillbaka den sträcker sig, innan du bestämmer dig för återställning kontra manuell städning.
5. Återställ från en känt ren backup i stället för att försöka städa bort skadlig kod fil för fil manuellt – det är lätt att missa en bakdörr som lämnats kvar, och en ren återställning är betydligt mer pålitlig än en manuell städning under tidspress.
6. Identifiera och stäng den faktiska ingångspunkten innan sajten går live igen fullt ut. Att återställa en backup utan att åtgärda sårbarheten som släppte in angriparen första gången bara nollställer klockan tills det händer igen.
7. Begär en granskning av skadlig kod från Google Search Console (eller relevant webbläsare/svartlistningsmyndighet) när du är säker på att sajten är ren, så att en eventuell varning om att sajten kan vara hackad tas bort så snabbt som möjligt.

Att ha den här sekvensen nedskriven och överenskommen innan en incident inträffar är värt betydligt mer än att försöka minnas rätt steg under press en fredag klockan elva på kvällen.

Webbplatssäkerhet är inte något man ställer in en gång och sedan bockar av – det är en löpande praktik av uppdateringar, övervakning och testade backuper, på samma sätt som att låsa kontorsdörren varje kväll är en vana snarare än ett engångsbeslut. Om du hellre vill ha det här hanterat som en stående del av hur din sajt sköts täcker vår tjänst för webbplatsunderhåll precis det här: hantering av SSL och uppdateringar, backuper som faktiskt testas, säkerhetsövervakning och ett snabbt, inövat svar om något ändå går fel. Hör gärna av dig via kontaktsidan om du vill ha en second opinion på hur ditt nuvarande upplägg står sig.