- Konu sahibi
- #1
CDN üzerinden yüklenen betikler hangi güven ilişkisini oluşturur?
CDN üzerinden yüklenen bir JavaScript betiğine yalnızca dosya sağlayıcısı olarak değil, sayfanızın çalışma anındaki bir bileşeni olarak güvenmiş olursunuz. Betik tarayıcıda kendi ayrı kutusunda çalışmaz; sayfanızın origin’i içinde çalıştığı için DOM’a, sayfadaki verilere ve izin verilen tarayıcı özelliklerine erişebilir. CDN bağlantısının HTTPS olması aktarım yolunu korur, ancak betiğin güvenli veya değiştirilmemiş olduğunu tek başına kanıtlamaz.
Oluşan güven ilişkisi nasıl çalışır?
Bir sayfa harici bir betik yüklediğinde tarayıcı şu zinciri izler:
- Sayfa, betiğin bulunduğu CDN adresine istek gönderir.
- CDN yanıtındaki JavaScript kodu indirilir ve sayfanın bağlamında çalıştırılır.
- Kod, sayfanın DOM’unu değiştirebilir; form alanlarını okuyabilir; kullanıcı etkileşimlerini izleyebilir ve erişebildiği uygulama verilerini başka bir yere gönderebilir.
- CDN hesabı, dağıtım hattı, alan adı, DNS, önbellek veya sürüm etiketi ele geçirilirse sayfanızda beklemediğiniz kod çalışabilir.
Bu nedenle güven, yalnız CDN işletmecisine değil; kullanılan sürüme, dağıtım yoluna, önbellek davranışına ve betiğin bütünlüğünü doğrulama yöntemine de dayanır. CORS ayarı bu durumu çözmez. CORS çoğunlukla başka origin’lerin yanıtı okuyup okuyamayacağını belirler; sayfanın kendisinin çalıştırdığı harici betiğe verilen yetkileri geri almaz.
Somut örnek
Varsayımsal olarak bir analiz betiğini CDN’den yükleyen ödeme sayfasını düşünün. Betik yalnızca ziyaretçi sayısını ölçmek üzere seçilmiş olabilir. Ancak aynı betik sayfadaki e-posta alanını, sepet içeriğini veya aynı sayfanın DOM’unda duran ödeme formundaki verileri okuyabiliyorsa güven ilişkisi analiz hizmetiyle sınırlı değildir; bu verilerin işlendiği tüm kod sürümlerini kapsar.
Bu, ayrı origin’deki ödeme iframe’inin içeriğini okuyabildiği anlamına gelmez; aynı origin politikası gibi tarayıcı sınırları sürer. CDN’de sabit bir sürüm yerine
latest gibi değişken bir etiket kullanılması bu riski büyütür. Sağlayıcı yeni sürüm yayınladığında sayfanızdaki kod, sizin dağıtım sürecinizden geçmeden değişebilir.Kararı şu şekilde verebilirsiniz:
| Yaklaşım | Güven modeli | Uygun kullanım |
|---|---|---|
| Kendi sunucunuzda barındırma | Dağıtım ve güncelleme sorumluluğu sizdedir | Kritik veya hassas sayfalar |
| CDN + sabit sürüm + SRI | İndirilen dosyanın baytları beklenen özetle karşılaştırılır | İçeriği seyrek değişen kütüphaneler |
| CDN + değişken sürüm etiketi | Sağlayıcının her yeni çıktısına güvenilir | Kritik olmayan, kontrollü senaryolar |
| Dinamik üçüncü taraf betiği | Çalışan içerik her yüklemede değişebilir | Ek inceleme ve daraltılmış yetkiler gereken durumlar |
Tablodaki seçenekler arasında en önemli fark, değişikliğin sizin onayınız olmadan üretime girip giremeyeceğidir. Kritik sayfalarda yalnızca kaynağın tanınmış olması yeterli kabul edilmemelidir.
Uygulanabilir güvenlik adımları
- Betik başına gerçekten ihtiyaç duyulan erişimi belirleyin. Ödeme, giriş ve kişisel veri içeren sayfalarda gereksiz üçüncü taraf betiklerini kaldırın. Yetkiyi yalnız işlev tanımıyla daraltamazsınız; gerekiyorsa ayrı origin/sandbox gibi gerçek izolasyon tasarlayın.
- Kullanılan dosyayı değişken etiket yerine sabit bir sürümle çağırın. Güncelleme gerektiğinde dosyayı önce inceleyip kendi dağıtım sürecinizden geçirin.
- Dosya değişmemeli ise Subresource Integrity kullanın. SRI özeti, tarayıcının indirdiği dosyanın beklenen içerikle aynı olup olmadığını denetler; özet uyuşmazsa betik çalıştırılmaz. Cross-origin SRI yüklemesinde crossorigin="anonymous" niteliği ve CDN’nin uygun Access-Control-Allow-Origin yanıtı da gerekir. SRI, seçtiğiniz içeriğin zararsız olduğunu kanıtlamaz.
- Content Security Policy ile yalnızca gerekli script kaynaklarını izinli listeye alın.
script-srcpolitikasını geniş bir joker karakterle açmak, CDN güven ilişkisinin sınırlarını fiilen kaldırır. - Tarayıcı konsolunu ve yapılandırdıysanız CSP raporlarını izleyin. Betik yüklenmiyorsa önce SRI özetinin dosyayla eşleştiğini, CSP’nin kaynağa izin verdiğini ve CDN’nin doğru içerik türünü döndürdüğünü kontrol edin.
- Güncelleme sürecine kaldırma planı ekleyin. Sağlayıcı güvenilirliğini kaybederse betiği kendi barındırdığınız doğrulanmış kopyayla değiştirebilmeli veya işlevi devre dışı bırakabilmelisiniz.
SRI kullandığınız halde betik dinamik olarak başka bir JavaScript dosyası veya yapılandırma indiriyorsa yalnızca ilk dosyanın bütünlüğünü doğrulamış olursunuz. Bu durumda yüklenen zincirin tamamını incelemek, mümkünse bağımlılıkları sabitlemek ve hassas sayfalarda üçüncü taraf çalıştırmamak gerekir.
Sık yapılan anlamlı hatalar
HTTPS’yi içerik güvenliğiyle karıştırmak, CDN alan adını CSP’de gereğinden geniş izinlerle tanımlamak ve dosya sürümünü sabitlememek en yaygın hatalardır. Ayrıca SRI özeti ekleyip güncelleme sonrasında bütünlük değerini yenilememek betiğin çalışmamasına yol açabilir. Çalışmaması çoğu zaman güvenlik mekanizmasının beklenen sonucudur; özeti kaldırmak yerine yeni dosyanın gerçekten incelenmiş sürümü için yeni özet oluşturulmalıdır.
Sık sorulan sorular
Betiği kendi sunucuma kopyalamak inceleme ihtiyacını kaldırır mı?
Hayır. Dağıtılan baytları kontrol etmeniz kolaylaşır, fakat zararlı veya hatalı kod kopyada da çalışır. Kaynağın lisansını, bağımlılıklarını ve güncelleme sorumluluğunu değerlendirip hangi sürümü dağıttığınızı kaydedin.Bir betiğe nonce vermek CDN’ye duyulan güveni ortadan kaldırır mı?
Hayır. Nonce, betiğin mevcut sayfa tarafından yetkilendirilip yetkilendirilmediğini gösterir; yetkilendirilen harici dosyanın ne yaptığını doğrulamaz. Kaynak güveni için sabit sürüm, SRI, dar CSP ve gerektiğinde kendi barındırmanız birlikte değerlendirilmelidir.
