Kort sagt: Et statisk website består af færdige HTML-, CSS- og billedfiler, som webserveren kun leverer. Fordi der ikke kører PHP og ingen database på serveren, falder sårbarheder som PHP2Shell, SQL-injektion eller indsmuglede webshells stort set bort som risiko. For sikkerheden af et statisk website tæller til gengæld andre ting: beskyttede adgange til hosting, domæne og build-værktøjer, vedligeholdte afhængigheder og omhyggeligt udvalgte eksterne tjenester. Det egner sig især til websites, der sjældent ændres og ikke har brug for kundekonti.
Hvorfor spørgsmålet stilles netop nu
PHP2Shell har vist mange virksomheder, hvor meget der hænger på en enkelt komponent. Et virksomhedswebsite med ti sider, som opdateres én gang i kvartalet, kørte på det samme PHP som en stor onlineshop og var dermed udsat for den samme kritiske sårbarhed. Ifølge medierapporter har selv myndigheder og kommuner forebyggende lukket websites ned.
Da ligger spørgsmålet nær: Har vi overhovedet brug for PHP på serveren til vores website? For mange små og mellemstore virksomheder lyder det ærlige svar: til leveringen ofte ikke. PHP genererer siden på ny ved hvert opkald, selv om indholdet ikke har ændret sig i ugevis. Hvordan det teknisk forløber, beskriver Sådan genererer PHP en webside. Hvad sårbarheden selv betyder, forklarer Hvad er PHP2Shell?.
Sådan fungerer et statisk website
Ved et statisk website genereres siden ikke ved besøget, men på forhånd. En generator til statiske sider, f.eks. Hugo, Jekyll eller Eleventy, tager tekster, billeder og skabeloner og bygger færdige filer af dem. Disse filer lægges på en enkel webserver eller et content delivery-netværk, altså et fordelt leveringsnetværk.
For redaktører kan et redigeringsværktøj sidde foran, som modtager ændringer og udløser genopbygningen. Delvis bruges dertil et såkaldt headless-CMS, der kun administrerer indhold og selv ikke behøver være offentligt tilgængeligt. Den besøgende ser intet af det; vedkommende modtager kun de færdige filer.
Statisk website og sikkerhed sammenlignet
| Kriterium | Dynamisk PHP-CMS | Statisk website |
|---|---|---|
| Programlogik på den offentlige server | Ja, ved hvert opkald | Nej |
| Risiko på grund af sårbarheder i PHP-fortolkeren | Ja, som ved PHP2Shell | Falder bort på leveringsserveren |
| Database offentligt tilsluttet | Ja | Nej |
| Typiske indgangsveje | Plugins, admin-login, uploads, server | Adgange til hosting, domæne, build-system, eksterne tjenester |
| Formularer, søgning, kundekonto | Indbygget | Kun via eksterne tjenester eller separate funktioner |
| Vedligeholdelsesindsats for redaktører | Lav, vante flade | Afhænger af redaktionsværktøjet |
| Vedligeholdelse | Regelmæssige opdateringer af CMS, plugins og PHP | Opdateringer af build-værktøjer og afhængigheder |
| Egnethed | Shops, portaler, mange redaktører, hyppige ændringer | Virksomhedswebsites, landingpages, dokumentation |
Tabellen viser: Angrebsfladen flytter sig, den forsvinder ikke. I stedet for en offentligt tilgængelig PHP-server skal I beskytte kontoen hos hostingudbyderen, domænet, build-pipelinen og eventuelt redaktionsværktøjet.
Hvilke risici der består ved statiske websites
For det første adgangene. Den, der overtager hostingkontoen, domæneadgangen eller kode-repositoryet, kan ændre websitet, helt uden PHP. Totrinslogin og personlige konti er derfor pligt.
For det andet afhængighederne. Generatorer og skabeloner medbringer ofte mange pakker, f.eks. fra npm. Disse skal holdes opdateret, fordi en kompromitteret afhængighed ved bygningen kan skrive skadelig kode ind i de færdige filer. Hvordan I organiserer det, beskriver Hold afhængigheder opdateret.
For det tredje eksterne tjenester. Formulartjenester, søgefunktioner, analyseværktøjer og indbundne scripts kører i de besøgendes browser eller på fremmede servere. Hver af disse tjenester er et tillidsforhold, også databeskyttelsesretligt.
For det fjerde browsersiden. Også en statisk side bør sætte sikkerhedsheadere, f.eks. en Content Security Policy, der fastlægger, hvilke scripts der må indlæses. Grundlaget står under Sikkerhedsheadere til websites.
Kontrollér før et skifte, hvilke funktioner jeres website virkelig bruger. Ofte er det færre end tænkt: sider, billeder, en kontaktformular. Så er vejen til det statiske website kortere, end den først ser ud.
For hvem skiftet kan betale sig, og for hvem ikke
Et statisk website egner sig godt til virksomhedssider af overskueligt omfang, landingpages til kampagner, produktdokumentation og karrieresider. Skiftet kan især betale sig, hvis det hidtidige website kører på en gammel PHP-version, og en opgradering alligevel stod for døren.
Mindre egnet er det til onlineshops, kundeportaler, bookingsystemer og websites med mange redaktører, der publicerer dagligt. Her forbliver et dynamisk system fornuftigt. En blandingsform kan hjælpe: Shoppen forbliver dynamisk og hærdes godt, vejledninger og virksomhedssider leveres statisk.
En ofte undervurderet fordel viser sig i en nødsituation. Fordi de færdige filer til enhver tid kan bygges på ny ud fra skabeloner og indhold, kan et manipuleret website hurtigt sættes tilbage til en kendt, ren status. Forudsætningen er, at indhold og skabeloner ligger i et beskyttet repository, ændringer logføres forståeligt, og ingen redigerer filerne direkte på serveren.
En sikkerhedsleverandør har I ikke nødvendigvis brug for til skiftet; det kan et bureau eller en udvikler overtage. Hvis det hidtidige website var kompromitteret, bør indhold dog kontrolleres, før det overtages. Det behandler Skifte CMS efter hacket?.
Hvordan hjælper PHP SOS konkret?
- Vi kontrollerer, hvilke funktioner jeres website faktisk har brug for, og siger åbent, om en statisk løsning egner sig.
- Ved et skifte sikrer vi adgangene til hosting, domæne og build-system med totrinslogin og personlige konti.
- Vi gennemgår eksterne tjenester og sætter sikkerhedsheadere, så det nye website også er godt beskyttet i browseren.
- Til PHP-systemer, der forbliver, overtager vi opdateringer og overvågning i sikkerhedsvedligeholdelsesaftalen.
Konklusion
Et statisk website er ikke et universalmiddel, men for mange virksomhedssider den enkleste måde at slippe af med en hel klasse af risici. Hvor der ikke kører PHP, kan PHP2Shell ikke udrette noget. Den vundne sikkerhed holder dog kun, hvis adgange, afhængigheder og eksterne tjenester tages lige så alvorligt, som serveren tidligere blev.
Ofte stillede spørgsmål
Kan man alligevel hacke et statisk website?
Ja. Den serverside programlogik falder bort, og dermed en stor klasse af angreb. Angribelige forbliver dog adgange til hosting, domæne og build-system, indbundne eksterne tjenester og de værktøjer, som siden produceres med.
Kan et statisk website have kontaktformularer?
Ja, via en ekstern formulartjeneste eller en lille, separat drevet funktion. Så ligger behandlingen af dataene hos denne tjeneste. Afklar databeskyttelse og databehandling, før I indbinder den.
Kan redaktører selv vedligeholde et statisk website?
Med et passende redaktionsværktøj ja. Mange løsninger tilbyder en redigeringsflade, hvorfra siden derefter genereres på ny. For teams, der dagligt ændrer mange indhold, er et klassisk CMS dog ofte mere bekvemt.
Kan skiftet betale sig for en onlineshop?
Som regel ikke fuldt ud. Indkøbskurv, kundekonto og betaling kræver serverside logik. Det er muligt at levere dele som vejledninger eller virksomhedssider statisk og drive shoppen separat.