Kort sagt: En statisk webbplats består av färdiga HTML-, CSS- och bildfiler som webbservern bara levererar. Eftersom varken PHP eller databas körs på servern faller luckor som PHP2Shell, SQL-injektion eller insmugglade webshells i stort sett bort som risk. För säkerheten hos en statisk webbplats räknas i stället andra saker: skyddade åtkomster till hosting, domän och byggverktyg, underhållna beroenden och noga utvalda externa tjänster. Den lämpar sig framför allt för webbplatser som sällan ändras och inte behöver några kundkonton.
Varför frågan ställs just nu
PHP2Shell har visat många företag hur mycket som hänger på en enda komponent. En företagswebbplats med tio sidor som uppdateras en gång i kvartalet körde på samma PHP som en stor webbshop och var därmed utsatt för samma kritiska lucka. Enligt medierapporter har till och med myndigheter och kommuner stängt av webbplatser i förebyggande syfte.
Då ligger frågan nära: Behöver vi över huvud taget PHP på servern för vår webbplats? För många små och medelstora företag lyder det ärliga svaret: för själva leveransen ofta inte. PHP skapar sidan på nytt vid varje anrop, fast innehållet inte har ändrats på veckor. Hur det tekniskt går till beskriver Hur PHP skapar en webbsida. Vad luckan själv innebär förklarar Vad är PHP2Shell?.
Så fungerar en statisk webbplats
Vid en statisk webbplats skapas sidan inte vid besöket utan i förväg. En generator för statiska sidor, till exempel Hugo, Jekyll eller Eleventy, tar texter, bilder och mallar och bygger färdiga filer av dem. Dessa filer laddas upp på en enkel webbserver eller ett content delivery-nät, alltså ett distribuerat leveransnät.
För redaktörer kan ett redigeringsverktyg sitta framför som tar emot ändringar och utlöser ombyggnaden. Delvis används för det ett så kallat headless-CMS som bara förvaltar innehåll och självt inte behöver vara offentligt nåbart. Besökaren ser inget av det; hen får bara de färdiga filerna.
Statisk webbplats och säkerhet i jämförelse
| Kriterium | Dynamiskt PHP-CMS | Statisk webbplats |
|---|---|---|
| Programlogik på den offentliga servern | Ja, vid varje anrop | Nej |
| Risk genom luckor i PHP-tolken | Ja, som vid PHP2Shell | Faller bort på leveransservern |
| Databas offentligt ansluten | Ja | Nej |
| Typiska ingångar | Tillägg, administratörsinloggning, uppladdningar, server | Åtkomster till hosting, domän, byggsystem, externa tjänster |
| Formulär, sökning, kundkonto | Inbyggt | Bara via externa tjänster eller separata funktioner |
| Underhållsinsats för redaktörer | Låg, välbekant gränssnitt | Beroende av redaktionsverktyget |
| Underhåll | Regelbundna uppdateringar av CMS, tillägg och PHP | Uppdateringar av byggverktyg och beroenden |
| Lämplighet | Webbshoppar, portaler, många redaktörer, täta ändringar | Företagswebbplatser, landningssidor, dokumentation |
Tabellen visar: Angreppsytan förskjuts, den försvinner inte. I stället för en offentligt nåbar PHP-server måste ni skydda kontot hos hostingleverantören, domänen, byggpipelinen och i förekommande fall redaktionsverktyget.
Vilka risker som kvarstår vid statiska webbplatser
För det första åtkomsterna. Den som tar över hostingkontot, domänåtkomsten eller kodförrådet kan förändra webbplatsen, helt utan PHP. Tvåfaktorsinloggning och personliga konton är därför ett måste.
För det andra beroendena. Generatorer och mallar tar ofta med sig många paket, till exempel från npm. Dessa måste hållas aktuella eftersom ett komprometterat beroende vid bygget kan skriva skadlig kod i de färdiga filerna. Hur ni organiserar det beskriver Håll beroenden aktuella.
För det tredje externa tjänster. Formulärtjänster, sökfunktioner, analysverktyg och inbundna skript körs i besökarnas webbläsare eller på främmande servrar. Varje sådan tjänst är ett förtroendeförhållande, även dataskyddsrättsligt.
För det fjärde webbläsarsidan. Även en statisk sida bör sätta säkerhetsheaders, till exempel en Content-Security-Policy som anger vilka skript som får laddas. Grunderna står under Säkerhetsheaders för webbplatser.
Pröva före en övergång vilka funktioner er webbplats verkligen använder. Ofta är det färre än man tror: sidor, bilder, ett kontaktformulär. Då är vägen till den statiska webbplatsen kortare än den först verkar.
För vem övergången lönar sig och för vem inte
Väl lämpad är en statisk webbplats för företagssidor av överskådlig omfattning, landningssidor för kampanjer, produktdokumentation och karriärsidor. Övergången lönar sig särskilt om den hittillsvarande webbplatsen körs på en gammal PHP-version och en uppgradering ändå skulle stå på tur.
Mindre lämpad är den för webbshoppar, kundportaler, bokningssystem och webbplatser med många redaktörer som publicerar dagligen. Där förblir ett dynamiskt system rimligt. En blandform kan hjälpa: Webbshoppen förblir dynamisk och härdas väl, guider och företagssidor levereras statiskt.
En ofta underskattad fördel visar sig i ett skarpt läge. Eftersom de färdiga filerna när som helst kan byggas om från mallar och innehåll går en manipulerad webbplats snabbt att återställa till ett känt, rent läge. Förutsättningen är att innehåll och mallar ligger i ett skyddat förråd, att ändringar protokollförs spårbart och att ingen redigerar filerna direkt på servern.
En säkerhetsleverantör behöver ni inte nödvändigtvis för övergången; det kan en byrå eller en utvecklare ta hand om. Om den hittillsvarande webbplatsen var komprometterad bör innehållet dock granskas före övertagandet. Det går Byta CMS efter hacket? in på.
Hur hjälper PHP SOS konkret?
- Vi prövar vilka funktioner er webbplats faktiskt behöver och säger öppet om en statisk lösning lämpar sig.
- Vid en övergång skyddar vi åtkomsterna till hosting, domän och byggsystem med tvåfaktorsinloggning och personliga konton.
- Vi granskar externa tjänster och sätter säkerhetsheaders så att den nya webbplatsen också är väl skyddad i webbläsaren.
- För PHP-system som blir kvar tar vi över uppdateringar och övervakning i säkerhetsunderhållsavtalet.
Slutsats
En statisk webbplats är inget universalmedel, men för många företagssidor det enklaste sättet att bli av med en hel klass av risker. Där ingen PHP körs kan PHP2Shell inte åstadkomma något. Den vunna säkerheten håller dock bara om åtkomster, beroenden och externa tjänster tas lika på allvar som servern tidigare.
Vanliga frågor
Går en statisk webbplats ändå att hacka?
Ja. Den serverside-programlogik som faller bort tar med sig en stor klass av angrepp. Angripbara förblir dock åtkomsterna till hosting, domän och byggsystem, inbundna externa tjänster och de verktyg som sidan skapas med.
Kan en statisk webbplats ha kontaktformulär?
Ja, via en extern formulärtjänst eller en liten, separat driven funktion. Då ligger behandlingen av uppgifterna hos den tjänsten. Klargör dataskydd och personuppgiftsbiträdesavtal innan ni binder in den.
Kan redaktörer själva sköta en statisk webbplats?
Med ett lämpligt redaktionsverktyg ja. Många lösningar erbjuder ett gränssnitt för redigering, varefter sidan skapas på nytt. För team som varje dag ändrar mycket innehåll är ett klassiskt CMS dock ofta bekvämare.
Lönar sig övergången för en webbshop?
Oftast inte fullt ut. Varukorg, kundkonto och betalning kräver serverside-logik. Det är möjligt att leverera delar som guider eller företagssidor statiskt och driva webbshoppen separat.