CDN Bağımlılıklarınızda Gizlenen Tehlikeler: Bir Domain Ele Geçirme Hikayesinden Dersler

Her web sitesi aslında iki farklı koddan oluşuyor: sizin yazdığınız kodlar ve güvendiğiniz kodlar. Geliştiricilerin büyük çoğunluğu ilkine büyük özen gösterirken, ikincisi çoğu zaman göz ardı ediliyor. Yakın tarihte yaşanan bir olay, bu dengesizliği acı bir şekilde gözler önüne serdi ve her geliştiricinin üçüncü taraf bağımlılıklarını gözden geçirmesi gerektiğini hatırlattı.

Kimsenin İstemediği Domain Hikayesi

Şöyle düşünün: Binlerce WordPress sitesine yıllarca hizmet veren sevilen bir CDN servisi bir gün kapılarını kapatıyor. Şirket satın alınıyor, operasyonlar sona eriyor ve sonunda domain kaydı düşüyor. Başka biri bu domaini alıyor ve artık sizin tüm alt domainlerinizi, dolayısıyla tüm varlıklarınızı (assets) kontrol ediyor.

Bu sadece teorik bir senaryo değil. Yaşanan gerçek bir olay bu. netdna-ssl.com, MaxCDN'nin arkasındaki asset domainiydi ve birçok WP Engine müşterisi statik içerik sunumu için bu servise güveniyordu. MaxCDN StackPath tarafından satın alındıktan sonra kapatılınca, domain serbest kaldı ve Temmuz 2025'te sessizce yeniden kaydedildi.

Yeni sahip, *.wpengine.netdna-ssl.com namespace'indeki tüm wildcard DNS kayıtlarını kontrol eder hale geldi. Sitenizde hâlâ referans verilen tüm hash tabanlı alt domainler mi? Artık tamamen yabancı birinin elindeydi; Google AdSense'li bir Instagram indirici sitesi çalıştıran biri, bu kontrolü ele geçirmişti.

Neden Bu Kadar Önemli?

Belki şöyle düşünüyorsunuz: "Ee ne olacak ki? Kimse artık bunu kullanmıyor. Eski bir altyapı." Ama sezginiz sizi yanıltabilir.

Araştırmalar, yalnızca GitHub'da bile bu eski domainlere hâlâ referans içeren yaklaşık 4.000 dosya olduğunu gösteriyor. Terk edilmiş repolardan bahsetmiyoruz—Mozilla'nın webxr-polyfill'i, Kong, Nextcloud, Yale Daily News ve daha birçok kuruluşun siteleri hâlâ bu kapatılmış uç noktalardan varlık çekiyor.

Daha da düşündürücü olanı? Cloudflare Radar, netdna-ssl.com'u dünya genelinde en çok ziyaret edilen 20.000 domain arasına koyuyor. Bu, gerçek tarayıcıların bu domaini hâlâ çözdüğü ve önemli miktarda trafik aldığı anlamına geliyor. Bunlar arkeolojik kalıntılar değil; aktif, canlı bağımlılıklar.

Yüklü Silah Problemi

İşte bu durumu gerçekten tehlikeli kılan şey. Şu an bu eski asset URL'leri temelde bozuk durumda. Yeni sahip Cloudflare'ı standart bir SSL sertifikasıyla kurmuş, ancak bu sertifika apex domain ve bazı proxy alt domainlerini kapsıyor, eski asset hostları için wildcard pattern'ı kapsamıyor. Tarayıcı xyz123.wpengine.netdna-ssl.com gibi bir alt domainden script veya font yüklemeye çalıştığında, TLS el sıkışması başarısız oluyor.

Kısa vadede bu kullanıcıları koruyor. Tarayıcı içeriği çalıştırmak yerine engelliyor. Ama şunu düşünün: saldırgan zaten tüm DNS kontrolüne sahip. Zaten para kazanma altyapısı çalışıyor. Zaten hosting kurulu. Bunu bir felakete dönüştüren tek şey, Cloudflare'ın Advanced Certificate Manager'ındaki tek bir yapılandırma değişikliği.

Güvenlik profesyonellerinin "yüklü silah" dediği şey tam olarak bu—şu anda istismar edilemeyen ama saldırganın minimal çabayla felakete dönüştürebileceği bir açıklık.

Bunu Daha Önce Yaşadık

Bu senaryo size tanıdık geliyorsa, bunun sebebi Haziran 2024'te polyfill.io ile aynı şeyin yaşandığına tanık olmamız. Tüm web'in güvenmeyi öğrendiği bir domain el değiştirdi ve 100.000'den fazla site birdenbire tamamen farklı niyetler taşıyan bir operatörden kod sunar halde buldu. Güven modeli çöktü çünkü "bu domain her zaman güvenli içerik sundu"yu "bu domain her zaman güvenli içerik sunacak" zannettik.

Rahatsız edici gerçek şu: güvenliğimizi domainlere değil, kodlara bağlamamız gerekirken domainlere bağlıyoruz. Domainler el değiştirdiğinde, ona güvenen her site yeni sahibin niyetini—ne olursa olsun—devralmış oluyor.

Hemen Yapmanız Gerekenler

Bağımlılıklarınızı derhal denetleyin. Kod tabanlarınızda, veritabanlarınızda ve belgelerinizde kullanımdan kaldırılmış veya üçüncü taraf CDN domainlerine referans arayın. Bir servis kapandı diye domainlerinin etkisiz olduğunu varsaymayın.

Kritik varlıkları kendiniz barındırmayı düşünün. Bir font, script veya stil dosyası uygulamanız için vazgeçilmezse, bunu içeri alın. Minik bir altyapı maliyeti, kullanıcılarınızın tarayıcılarının güvenilmeyen bir kaynaktan kod indirmesi riskine göre önemsiz kalır.

Subresource Integrity (SRI) uygulayın. Üçüncü taraf CDN kaynakları kullanmak zorundaysanız, <script> ve <link> etiketlerinize kriptografik hash'ler ekleyin. SRI, bir saldırgan domaini kontrol etse bile, bütünlük kontrolünüzü bozmadan değiştirilmiş kod sunmasını engeller.

Tedarik zincirinizi izleyin. Report URI ve çeşitli CSP izleme araçları gibi servisler, güvenlik raporlarınızda beklenmedik domainlerin görünmesi konusunda sizi uyarabilir. Bu uyarıları kurun ve ciddiye alın.

Büyük Resim

Bu olay, modern web geliştirmesindeki temel bir gerilimi gözler önüne seriyor: güven üzerine inşa ediyoruz ama bu güveni zaman içinde denetlemeyi nadiren düşünüyoruz. Geçen yıl tamamen güvenli olan bir bağımlılık, domain el değiştirirse önümüzdeki yıl malware servis edebilir.

NameOcean'da domain güvenliğinden çok bahsediyoruz—DNSSEC, SSL sertifikaları, registrar kilitleri gibi konular. Ama bu hikayeler bize gerçek güvenlik meydan okumasının sadece kendi domainlerinizi korumak olmadığını hatırlatıyor; güvendiğiniz domainleri bilinçli seçmek ve bu güvenin suiistimal edilebileceğini tespit etmek için sistemler kurmak da aynı derecede önemli.

Web güven üzerine çalışıyor. Emin olun, güveninizi akıllıca yerleştiriyorsunuz.