Den skjulte trussel i dine CDN-afhængigheder: Lærdomme fra et domæne-overtagelse

Alle hjemmesider består af kode, du selv skriver, og kode, du stoler på. De fleste udviklere bruger masser af tid på at sikre det første. Men det andet får sjældent samme opmærksomhed. En ny opdagelse i branchen har bragt denne ubalance i fokus – og den bør give enhver udvikler grund til at gennemgå deres tredjeparts-afhængigheder.

Historien om et domæne, ingen længere ville have

Forestil dig dette: En populær CDN-tjeneste, der havde drevet tusindvis af WordPress-sider i over et årti, lukker pludselig ned. Virksomheden bliver opkøbt, driften afvikles, og til sidst udløber domæneregistreringen. En anden person registrerer det, og denne person kontrollerer nu alle underdomæner, der nogensinde har peget på jeres assets.

Dette er ikke en teoretisk øvelse. Det er præcis, hvad der skete med netdna-ssl.com – det asset-domæne, der lå bag MaxCDN, en tjeneste mange WP Engine-kunder brugte til at levere statisk indhold. Da MaxCDN blev overtaget af StackPath og siden lukket, lod man domænet udløbe. I juli 2025 blev det stille registreret af en ny ejer.

Den nye indehaver fik øjeblikkeligt kontrol over wildcard DNS på tværs af hele *.wpengine.netdna-ssl.com-navneområdet. Alle hash-baserede underdomæner, som dit site måske stadig refererer til? Nu kontrolleret af en komplet fremmed, der driver et Instagram-download site med Google AdSense.

Hvorfor dette betyder mere, end du tror

Du tænker måske: "Hvad så? Ingen bruger det længere. Det er legacy-infrastruktur." Men her fejler intuitionen os.

Forskning viser, at cirka 4.000 filer på GitHub alene stadig indeholder referencer til disse forældede domæner. Vi taler ikke om forladte repositories – projekter som Mozillas webxr-polyfill, sammen med sider tilhørende Kong, Nextcloud, Yale Daily News og adskillige andre organisationer, henter stadig assets fra disse udgåede endpoints.

Endnu mere nedslående? Cloudflare Radar rangerer netdna-ssl.com blandt de top 20.000 domæner globalt. Det betyder, at rigtige browsere stadig opløser dette navn – i betydelig volumen. Dette er ikke arkæologiske kuriositeter; det er aktive, levende afhængigheder.

Problemet med den ladede pistol

Her er det, der gør situationen særligt farlig. Lige nu er disse legacy asset-URL'er i bund og grund i stykker. Den nye ejer har sat Cloudflare op med et standard SSL-certifikat, der dækker apex-domænet og nogle proxy-underdomæner, men ikke wildcard-mønstret for legacy asset-hosts. Når en browser forsøger at indlæse et script eller en font fra et underdomæne som xyz123.wpengine.netdna-ssl.com, fejler TLS-handshaken.

På kort sigt beskytter dette brugerne. Browsere blokkerer indholdet i stedet for at køre det. Men overvej, hvad dette betyder: Angriberen har allerede total DNS-kontrol. De har allerede monetiseringsinfrastruktur kørende. De har allerede hosting sat op. Det eneste, der adskiller dette fra en katastrofe, er en enkelt konfigurationsændring i Cloudflares Advanced Certificate Manager.

Dette er, hvad sikkerhedsprofessionelle kalder en "ladet pistol" – en sårbarhed, der ikke er udnyttelig lige nu, men som kan blive katastrofal med minimal indsats fra angriberen.

Vi har set denne film før

Hvis dette scenarie føles ubehageligt bekendt, er det fordi vi så det udfolde sig i juni 2024 med polyfill.io. Et domæne, hele internettet havde lært at stole på, skiftede hænder, og over 100.000 sider fandt sig pludselig i at levere kode fra en operatør med helt andre hensigter. Tillidsmodellen brød sammen, fordi vi forvekslede "dette domæne har altid leveret sikkert indhold" med "dette domæne vil altid levere sikkert indhold."

Den ubehagelige sandhed er, at vi forankrer vores sikkerhed i domæner frem for kode. Når domæner skifter hænder, arver alle sider, der stolede på dem, den nye ejers hensigter – hvad end de måtte være.

Hvad du bør gøre lige nu

Gennemgå dine afhængigheder omgående. Søg i dine kodebaser, databaser og dokumentation efter referencer til forældede eller tredjeparts CDN-domæner. Antag ikke, at fordi en tjeneste er lukket ned, er dens domæner inaktive.

Overvej at hoste kritiske assets selv. Hvis en font, et script eller et stylesheet er afgørende for din applikation, så tag det ind i huset. Den marginale infrastrukturpris er ubetydelig sammenlignet med risikoen for, at dine brugeres browsere henter kode fra en upålidelig kilde.

Implementer Subresource Integrity (SRI). Når du skal bruge tredjeparts CDN-ressourcer, skal du tilføje kryptografiske hashes til dine <script> og <link> tags. SRI sikrer, at selv hvis en angriber får kontrol over et domæne, kan de ikke levere modificeret kode uden at bryde dine integritetskontroller.

Overvåg din supply chain. Tjenester som Report URI og forskellige CSP-overvågningsværktøjer kan give dig besked, når uventede domæner dukker op i dine sikkerhedsrapporter. Opsæt disse alarmer og tag dem alvorligt.

Det store billede

Denne hændelse belyser en fundamental spænding i moderne webudvikling: vi bygger på tillid, men vi gennemgår sjældent denne tillid over tid. En afhængighed, der var fuldt ud sikker sidste år, kan muligvis levere malware næste år, hvis domænet skifter hænder.

Hos NameOcean taler vi meget om domænesikkerhed – DNSSEC, SSL-certifikater, registrar-låse. Men historier som denne minder os om, at den virkelige sikkerhedsudfordring ikke kun handler om at beskytte dine egne domæner; det handler om at være bevidst om, hvilke domæner du vælger at stole på i første omgang, og om at have systemer på plads til at opdage, når denne tillid kan være fejlplaceret.

Internettet kører på tillid. Sørg for, at din er placeret klogt.