Skjulte farer i dine CDN-avhengigheter: Lærdommer fra et domenekupp

Hvert nettsted er en miks av kode du skriver selv og kode du stoler på. De fleste utviklere bruker mye tid på å sikre den første kategorien, men den andre får langt mindre oppmerksomhet. En nylig oppdagelse har kastet lys over denne ubalansen, og avdekket et scenario som bør få enhver utvikler til å stoppe opp og sjekke sine tredjepartsavhengigheter.

Historien om et domene ingen lenger ville ha

Tenk deg dette: en populær CDN-tjeneste som betjente tusenvis av WordPress-nettsteder i over et tiår legger ned. Selskapet blir kjøpt opp, driften avvikles, og til slutt går domenereigstreringen ut. Noen andre plukker det opp, og denne personen kontrollerer nå alle subdomener som noensinne har pekt til dine ressurser.

Dette er ikke et tankeeksperiment. Dette er nøyaktig hva som skjedde med netdna-ssl.com, ressursdomenet bak MaxCDN. Da MaxCDN ble absorbert av StackPath og deretter lagt ned, fikk domenet utløpe. I juli 2025 ble det registrer på nytt av en ny eier.

Den nye eieren fikk umiddelbart kontroll over wildcard-DNS for hele *.wpengine.netdna-ssl.com-navnerommet. Hvert hash-baserte subdomene som nettstedet ditt kanskje fortsatt refererer til? Nå kontrollert av en fremmed som driver et Instagram-nedlastingsside med Google AdSense.

Hvorfor dette er viktigere enn du tror

Du tenker kanskje: "Og hva da? Ingen bruker dette lenger. Det er gammel infrastruktur." Men her svikter intuisjonen vår.

Forskning viser at rundt 4 000 filer på GitHub alene fortsatt inneholder referanser til disse gamle domenene. Vi snalker ikke om forlatte repositorier heller – prosjekter som Mozillas webxr-polyfill, samt nettsteder tilhørende Kong, Nextcloud, Yale Daily News og mange andre organisasjoner, henter fortsatt ressurser fra disse utgåtte endepunktene.

Enda mer nedslående? Cloudflare Radar rangerer netdna-ssl.com blant de topp 20 000 domenene globalt. Dette betyr at virkelige nettlesere fortsatt resolver dette navnet, i betydelig volum. Dette er ikke arkeologiske kuriositeter; de er aktive, levende avhengigheter.

Problemet med den ladede pistol

Her er det som gjør situasjonen spesielt farlig. Akkurat nå er disse gamle ressurs-URL-ene i praksis ødelagte. Den nye eieren har satt opp Cloudflare med et standard SSL-sertifikat som dekker apex-domenet og noen proxy-subdomener, men ikke wildcard-mønsteret for eldre ressursverter. Når en nettleser prøver å laste et skript eller en font fra et subdomene som xyz123.wpengine.netdna-ssl.com, feiler TLS-handshake.

På kort sikt beskytter dette brukerne. Nettleseren blokkerer innholdet i stedet for å kjøre det. Men tenk på hva dette betyr: Angriperen har allerede full DNS-kontroll. De har allerede monetiseringsinfrastruktur i gang. De har allerede hosting satt opp. Det eneste som skiller dette fra en katastrofe, er én konfigurasjonsendring i Cloudflares Advanced Certificate Manager.

Dette er det sikkerhetseksperter kaller en "ladet pistol" – et sikkerhetshull som for øyeblikket ikke er utnyttbart, men som kan bli katastrofalt med minimal innsats fra angriperen.

Vi har sett denne filmen før

Hvis dette scenarioet føles ubehagelig kjent, er det fordi vi så det utspille seg i juni 2024 med polyfill.io. Et domene hele nettet hadde lært å stole på, skiftet eier, og over 100 000 nettsteder fant seg plutselig til å servere kode fra en aktør med helt andre intensjoner. Tillitsmodellen brøt fordi vi forvekslet "dette domenet har alltid levert trygt innhold" med "dette domenet vil alltid levere trygt innhold."

Den ubehagelige sannheten er at vi forankrer sikkerheten vår i domener heller enn kode. Når domener skifter eier, arver hvert nettsted som stolte på dem, den nye eierens intensjoner – hva enn disse måtte være.

Hva du bør gjøre nå

Sjekk avhengighetene dine umiddelbart. Søk i kodebasene, databasene og dokumentasjonen din etter referanser til utgåtte eller tredjeparts CDN-domener. Anta ikke at fordi en tjeneste er nedlagt, er domenene deres inaktive.

Vurder selv-hosting av kritiske ressurser. Hvis en font, et skript eller et stilark er essensielt for applikasjonen din, ta det i hus. Den minimale infrastrukturbesparelsen er ubetydelig sammenlignet med risikoen for at brukernes nettlesere henter kode fra en upålitelig kilde.

Implementer Subresource Integrity (SRI). Når du må bruke tredjeparts CDN-ressurser, legg til kryptografiske hashverdier i <script>- og <link>-taggene dine. SRI sikrer at selv om en angriper får kontroll over et domene, kan de ikke levere modifisert kode uten å bryte integritetssjekkene dine.

Overvåk leverandørkjeden din. Tjenester som Report URI og ulike CSP-overvåkingsverktøy kan varsle deg når uventede domener dukker opp i sikkerhetsrapportene dine. Sett opp disse varslene og ta dem på alvor.

Det store bildet

Denne hendelsen belyser en fundamental spenning i moderne webutvikling: vi bygger på tillit, men vi sjelden reviderer den tilliten over tid. En avhengighet som var helt trygg i fjor, kan levere skadevare i morgen hvis domenet skifter eier.

Hos NameOcean snakker vi mye om domenering – DNSSEC, SSL-sertifikater, registrar låser. Men historier som denne minner oss om at den virkelige sikkerhetsutfordringen ikke bare er å beskytte dine egne domener; det er å være bevisst på hvilke domener du velger å stole på i utgangspunktet, og ha systemer på plass for å oppdage når den tilliten kan være feplassert.

Nettet er bygget på tillit. Pass på at din er plassert med omhu.