A rejtett veszélyek a CDN függőségeidben: tanulságok egy domain átvételből

Minden weboldal két világ találkozása: az általad írt kód és az a kód, amelyre egyszerűen rábízod magad. Az elsővel a legtöbb fejlesztő órákat tölt, a másodikkal viszont ritkán foglalkozik. Egy nemrég történt eset most élesen rávilágított erre az egyensúlyhiányra – és minden fejlesztőnek el kell gondolkodnia a harmadik féltől származó függőségein.

A történet arról a domainről, amelyet senki sem akart

Képzeld el: egy kedvelt CDN szolgáltatás, amely éveken át rengeteg WordPress oldalt működtetett, egyszer csak bezárja a kapuit. A céget felvásárolják, a működés leáll, végül a domain regisztráció lejár. És akkor valaki más bejegyzi – most már ő irányít minden aldomainet, amely valaha a te assetjeidre mutatott.

Ez nem elméleti szkenárió. Pontosan ez történt a netdna-ssl.com domainnel, ami a MaxCDN mögötti asset domain volt – egy szolgáltatás, amelyre sok WP Engine ügyfél támaszkodott a statikus tartalmak kiszolgálásánál. Amikor a MaxCDN-t a StackPath felvásárolta, majd végleg leállította, a domaint hagyták lejárni. Aztán 2025 júliusában csendesen újra bejegyezték.

Az új tulajdonos ezzel teljes DNS-ellenőrzést szerzett a teljes *.wpengine.netdna-ssl.com névtér felett. Minden hash-alapú aldomain, amelyet az oldalad még mindig hivatkozik? Most már egy teljesen idegen kezében van, aki egy Instagram letöltő oldalt üzemeltet Google AdSense-szel.

Miért fontos ez többet, mint gondolnád

Lehet, hogy most azt gondolod: "Na és? Senki nem használja már. Legacy infrastruktúra." De itt csúszik el a logikánk.

A kutatások szerint nagyjából 4,000 fájl a GitHub-on még mindig tartalmaz hivatkozásokat ezekre a legacy domainekre. És itt nem elhagyott repositorykról van szó – olyan projektek, mint a Mozilla webxr-polyfill, vagy a Kong, Nextcloud, Yale Daily News oldalai, és rengeteg más szervezet még mindig onnan tölti az asseteket.

És ami még aggasztóbb: a Cloudflare Radar szerint a netdna-ssl.com a globális top 20,000 domain között van. Ez azt jelenti, hogy valós böngészők még mindig feloldják ezt a nevet, jelentős mennyiségben. Ezek nem régészeti kuriózumok – aktív, élő függőségek.

A betöltött fegyver problémája

És itt válik igazán veszélyessé a helyzet. Jelenleg ezek a legacy asset URL-ek gyakorlatilag működésképtelenek. Az új tulajdonos beállította a Cloudflare-t egy szabványos SSL tanúsítvánnyal, amely az apex domaint és néhány proxy aldomaint fedi le, de a legacy asset hosztok wildcard mintáját nem. Amikor egy böngésző megpróbál betölteni egy scriptet vagy fontot egy olyan aldomainről, mint xyz123.wpengine.netdna-ssl.com, a TLS kézfogás meghiúsul.

Rövid távon ez védi a felhasználókat. A böngésző blokkolja a tartalmat, nem hajtja végre. De gondolj bele: a támadó már most teljes DNS-ellenőrzéssel rendelkezik. Már van monetizációra használt infrastruktúrája. Már van működő hostingja. Az egyetlen dolog, ami egy katasztrófától elválasztja, az egyetlen konfigurációs kapcsoló a Cloudflare Advanced Certificate Managerében.

Ez az, amit a biztonsági szakemberek "betöltött fegyvernek" hívnak – olyan sebezhetőség, amely jelenleg nem kihasználható, de minimális erőfeszítéssel katastrofálissá válhat.

Láttuk már ezt a filmet

Ha ez a szkenárió ismerősen hangzik, az azért van, mert 2024 júniusában végignéztük ugyanezt a polyfill.io kapcsán. Egy domain, amelyben az egész web megtanult megbízni, gazdát cserélt, és több mint 100,000 oldal hirtelen olyan kódot szolgáltatott, amelyet egy teljesen más szándékú üzemeltető írt. A bizalmi modell azért dőlt meg, mert összekevertük azt, hogy "ez a domain mindig biztonságos tartalmat szolgáltatott" azzal, hogy "ez a domain mindig biztonságos tartalmat fog szolgáltatni."

Kellemetlen igazság, hogy a biztonságunkat domainekhez kötjük, nem kódokhoz. Amikor egy domain gazdát cserél, minden oldal, amely megbízott benne, az új tulajdonos szándékát örökli – bármi is legyen az.

Mit tegyél most

Azonnal ellenőrizd a függőségeidet. Keresd meg a kódbázisaidban, adatbázisaidban és dokumentációidban minden hivatkozást az elavult vagy harmadik féltől származó CDN domainekre. Ne feltételezd, hogy mert egy szolgáltatás leállt, a domainjei inaktívak.

Fontold meg a kritikus assetek saját tárhelyre helyezését. Ha egy font, script vagy stíluslap létfontosságú az alkalmazásodhoz, tedd sajátra. Az infrastruktúra minimális költsége elhanyagolható ahhoz képest, hogy a felhasználók böngészője nem megbízható forrásból tölt kódot.

Implementálj Subresource Integrity-t (SRI). Amikor harmadik fél CDN erőforrásait kell használnod, adj kriptográfiai hash-eket a <script> és <link> tagjeidhez. Az SRI biztosítja, hogy még ha egy támadó át is veszi egy domain irányítását, nem tud módosított kódot kiszolgálni az integritás-ellenőrzések megtörése nélkül.

Figyeld a supply chain-et. Olyan szolgáltatások, mint a Report URI és különböző CSP monitoring eszközök jelezhetik, ha váratlan domainek jelennek meg a biztonsági jelentéseidben. Állítsd be ezeket a riasztásokat és vedd komolyan őket.

A nagy kép

Ez az eset egy alapvető feszültségre világít rá a modern webfejlesztésben: bizalomra építünk, de ritkán ellenőrizzük ezt a bizalmat idővel. Egy függőség, amely tavaly tökéletesen biztonságos volt, jövőre már rosszindulatú szoftvert szolgáltathat, ha a domain gazdát cserél.

A NameOcean-nál sokat beszélünk domain biztonságról – DNSSEC, SSL tanúsítványok, registrar zárak. De az ilyen történetek emlékeztetnek arra, hogy a valódi biztonsági kihívás nem csak a saját domainjeid védelme; hanem az, hogy átgondoltan válasszuk meg, mely domaineknek adjuk át a bizalmunkat, és legyenek rendszereink annak észlelésére, amikor ez a bizalom meginghat.

A web bizalomra épül. Győződj meg róla, hogy a tiéd bölcsen van elhelyezve.