Üçüncü Parti Script'ler Sizin Yetkinizle, Kendi Origin'inizde Çalışır

Bugün ticari amaçlı yayınlanan her web sayfası bir federasyondur. Ekip tarafından yazılan uygulamanın kodu, sayfada gerçekte yürütülen JavaScript'in çoğunlukla küçük bir kısmıdır. Geri kalanı çalışma zamanında gelir: analitik sağlayıcıları, tag manager'lar, chat ve destek widget'ları, KVKK/izin yönetim araçları, oturum kaydı (session replay) yazılımları, reklam pikselleri, fraud skorlama SDK'ları, müşteri destek portalları ve ödeme iframe'leri. Bir kısmını doğrudan kendi <script> etiketlerinizle çağırırsınız; önemli bir bölümü ise başka script'ler tarafından yüklenir. Yani kaynak kodunuz, müşterinizin tarayıcısında çalışan şeyin tam listesini taşımaz.

Temel değerlendirme: Üçüncü parti bir script kozmetik bir bağımlılık değildir. Sizin sayfanızda yürütüldüğü anda sizin origin yetkilerinizle ve kullanıcının açık oturumuyla çalışır. DOM'u okur, şifre ve kart alanlarınıza dinleyici takar, formlarınızı yeniden yazar, kullanıcıya doğru gösterdiği sayı ile sunucuya gönderdiği sayıyı farklılaştırabilir ve ağın izin verdiği her adrese istediği veriyi gönderebilir. Bu, sunucu tarafında ele geçirilmiş bir bağımlılığın aynı güven ilişkisidir — tek farkı, oturum açmış son kullanıcılara teslim edilmesi, CI hattınızda kimsenin onu görmemesi ve artifact'ınızın vendor'un takvimiyle neredeyse her gün değişmesidir. Bu riskin gözden kaçma nedeni cehalet değildir: dört ayrı kontrol bu tehlikenin her birine farklı bir açıdan bakar ve hiçbiri sizin işinize olan açıdan bakmaz. CSP zaten o origin'i serbest bırakıyor, WAF kodu hiç görmüyor, SAST hiç indirmedi, SBOM sunucuyu tarif ediyor.

Neden Ayrıcalıklı Bir Kod Yolu Olduğunu Anlamak

Zihinsel modeli bozan şey "üçüncü parti" ifadesinin "dışarıda" anlamına geldiği varsayımıdır. İstemci tarafında, yürütülen üçüncü parti içerik içeridedir.

Özellikle son iki satıra dikkat edin. Birçok uygulama, kolaylık olsun diye JWT, refresh token, çözümlenmiş kullanıcı profili ya da tam adres kayıtlarını istemcide saklar. Sayfadaki her script bunları okuyabilir. Bu, bir vendor ihlalini tek bir istek altyapınıza dokunmadan ölçekli bir token hırsızlığı olayına çevirir.

Kodun Sizin Sayfanıza Gelmesinin Gerçekçi Yolları

Dört yol vardır ve yalnızca birinde sizin ekibiniz hata yapar.

1. Vendor'un üst tarafının ele geçirilmesi. Sağlayıcının build sistemi, paket hesabı, CDN kovası veya yönetim paneli ihlal edilir. Etiketinizin URL'si değişmez, yanıt hâlâ doğru domain'den ve geçerli TLS sertifikasıyla gelir, içerik ise artık düşmandır. En zor budur, çünkü hiçbir konfigürasyonunuz hatalı değildir.

2. Self-service değişiklik. Pazarlama ve analitik platformlarının çoğu, müşteriye ya da vendor tarafındaki bir operatöre "custom HTML tag" ya da kural yayınlama imkânı tanır; kod incelemesi yoktur, yayılma dakikalar içinde olur. Tek bir ele geçirilmiş hesap binlerce sitenin gösterdiği içeriği değiştirir. Bu mekanizma hıza göre tasarlanmıştır, incelemeye göre değil.

3. Zincirleme yükleme. Bir script yüklersiniz, o altı script yükler. Sabitlediğiniz etiket, çalışan kod değildir. Yükleme sırası, A/B dallanması, coğrafya ya da user-agent koşuluna göre farklı ziyaretçiler farklı kod alır. "Bir kez kontrol etmiştik" bu yüzden kontrol sayılmaz.

4. Taşıma katmanında oynatma. Script'ler düz HTTP ile ya da ziyaretçinin ağından erişilebilen bir origin'den geliyorsa yolda değiştirilebilir. Modern kamusal yüzeylerde artık seyrektir; captive portal, otel ve konferans ağlarında, istemci kök deposunda güvenilir sayılan aracıların olduğu bölgelerde ise hâlâ rutindir.

Bir de beşinci, kötü niyetli olmayan durum vardır ve bütçelenmelidir: vendor sorunsuzdur, script hatalıdır. Sonsuz döngü, sınırı olmayan setInterval, hassas veriyi kapanışta (closure) tutup hiç bırakmayan bir dinleyici ya da sayfayı maliyet olayına çeviren tekrar deneme fırtınası. Etiket kaynaklı erişilebilirlik ve maliyet arızaları, düşmanca olanlardan daha sık yaşanır ve aynı envanter tarafından yönetilir.

Standart Kontroller Bu Riski Neden Göremez

Tartışmalar tam burada kirleniyor, o yüzden her kontrolün kör noktasını net söyleyelim.

• Content Security Policy. CSP hangi origin'lerin yürütebileceğini kısıtlar. Vendor'un origin'i allowlist'teyse — ki özellik bozulmasın diye olmak zorundadır — o origin'in servis ettiği her kod sizin onayınızla çalışır. Nonce ve hash de yardım etmez: bunlar sunucunuzun render anında bildiği script'ler için üretilir, tag manager'ın sonradan çektiği kod için değildir. strict-dynamic denetlenebilirlik açısından bunu bilinçli olarak daha kötüleştirir, çünkü çalışma zamanında enjekte edilen script'lere meşru şekilde izin verir. Raporlama (report-uri) yine de değerlidir: engellenecek olanı söyler ve kimsenin envanterlemediği bir script'i bu şekilde keşfedersiniz.
• WAF / RASP / ağ kenarı. Düşmanca kod, meşru bir domain'den gelen meşru bir yanıttır; tarayıcı ister, yerelde yürür, sızdırması analitik beacon'u gibi görünür. WAF yükü hiç görmez, script indikten sonra ne yaptığını zaten göremez.
• SAST / DAST. SAST deponuzu tarar; deponuzda etiketin içeriği yoktur. Oturum açmayan, kaydırma yapmayan veya yeterince uzun beklemeyen bir DAST örümceği gecikmeli yüklenen etiketleri hiç tetiklemez. Titiz bir örümcek bile A/B bölümün yalnızca bir dalını görür.
• SBOM / bağımlılık taraması. Bunlar derleme zamanı bileşenlerini tarif eder. Vendor origin'ini gösteren bir script etiketi artifact'ta yoktur, sürümü yoktur, vendor'un takviminde değişir.
• Subresource Integrity (SRI). Burada gerçekten işe yarayan tek kontrol olmakla birlikte, aşağıda tartışılacak nedeni yüzünden neredeyse hiç uygulanmaz.
• Vendor güvenlik anketleri. "Programınız var mı" sorusuna cevap verir; "Salı günü 03:00 ile 03:20 UTC arasında etiketiniz ne servis etti" sorusuna asla vermez.

Gerçeği Nasıl Ortaya Koyarsınız

Sıra önemlidir. Önce ölçün, sonra kısıtlayın.

Adım 1 — Kaynak envanteri değil, çalışma zamanı envanteri çıkarın. Gerçek sayfaları, oturum açmış halde yükleyip gerçekte neyin yürüdüğünü sayın: çözümlenmiş URL'leriyle her <script> etiketi, script başlatan performance.getEntriesByType("resource") kayıtları ve documentElement üzerinde bir MutationObserver ile yakalanan dinamik düğümler. Bunu tek sefer değil, sayfa şablonu başına ve günler boyunca tekrarlayın ki A/B dalları da yüzeye çıksın. Liste kimsenin tahmininden uzun çıkacak ve en az bir maddenin sahibi olmayacak.

Adım 2 — Her maddeyi bir sahibe ve bir amaca bağlayın. Üç faydalı soru: bunu hangi iç ekip istedi, bir gelir veya yasal fonksiyon için zorunlu mu, yüklenmezse ne olur. Maddelerin önemli bir kısmı üçünden de kalacak. O liste sizin silme listenizdir ve silme, herhangi bir şeyi izlemekten daha ucuz kontroldür.

Adım 3 — Script başına veri maruziyetini haritalayın. Her etiket için yürüdüğü andaki okunabilir durumu kaydedin: kullanıcı oturum açmış mı, DOM'da form var mı, sayfada ödeme veya kimlik alanı bulunuyor mu, istemci deposunda hassas bir şey duruyor mu. Sonra envanteri risk bandına göre bölün. Oturum açmış checkout sayfasındaki bir pazarlama pikseli ile kamusal blog yazısındaki aynı piksel aynı risk değildir; CSP kırılımı da bunu yansıtmalıdır.

Adım 4 — Dışarı çıkış varsayımını test edin. Etiket veriyi istediği adrese mi gönderiyor, yoksa yalnızca kendi origin'ine mi? Bu, icraya dönüştürülebilir bir politika sorusudur. Gözlemlenen beacon'ları beyan edilenlerle karşılaştırın. Kimsenin listelemediği bir host'a giden beyanı olmayan bir POST, bu çalışmanın en yüksek sinyalli bulgusudur.

Adım 5 — İçeriği değil, değişimi tespit edin. Servis edilen baytları sürekli izlemek gerçekçi cevaptır: her etiketin her çekimde ne servis ettiğini hash'leyin, değişimde alarm üretin ve değişim üretim kullanıcılarına ulaşmadan önce gerekçelendirilmesini isteyin. Birbirini tamamlayan iki icra yöntemi vardır:

• Sabitle ve kapalı tarafta hata ver. Bir etikeye SRI uygulamak, tarayıcının kayıtlı hash'e uymayan kodu yürütmeyi reddetmesi demektir. Gerçekten güçlüdür ve gerçek bir bedeli vardır: vendor deploy'ları sitenizi bozar. Bunu hafifletmek için yalnızca yüksek riskli alt kümeyi (checkout, kimlik doğrulama, hesap sayfaları) sabitleyin, bir fallback yolu tutun ve vendor ile değişim bildirimi için bir kanal müzakere edin.
• Hash'le, kaydet, alarm üret. Sabitlemenin pratik olmadığı yerlerde hash geçmişini sunucu tarafında tutun, kendi sayfa-telemetrinizle birlikte gönderin ve açıklanamayan değişimi olay sayın. Önlemeyi kaybedersiniz, tespiti korursunuz.

Sertleştirme, Gerçek Getiri Sırasıyla

1. Önce silin. Silinen her etiket kalıcı olarak kapanmış bir yoldur. Çoğu site, insanlar gerçekten bakınca etiketlerinin üçte birinden fazlasını ölçülebilir bir iş kaybı olmadan kaldırabilir.
2. Sırrı istemcide saklamayı bırakın. localStorage'daki token'lar, etiket oynamasını hesap ele geçirmeye çeviren güçlendiricidir. HttpOnly, SameSite kapsamalı ve kısa ömürlü cookie'ler ile dönen refresh token ödülü ortadan kaldırır.
3. Etiketleri kendiniz servis edin. Vendor script'lerini sizin kontrolünüzdeki bir first-party origin üzerinden, sunucu tarafında ya da sizin yönettiğiniz bir edge worker üzerinden proxy'leyin. Bu, aksi halde opak kalacak şeyi hash'leyebileceğiniz, önbelleğe alabileceğiniz, engelleyebileceğiniz ve sürümlendirebileceğiniz bir yer kazandırır ve CSP allowlist'ini dramatik biçimde daraltır. Sessizce vendor analitiğini de bozabilir; bütçeleme sırasında mutabakat payı bırakın.
4. Güvensiz olmak zorundaysa izole edin. İzin araçları, chat widget'ları ve destek portallerinin formlarınızın DOM'una ihtiyacı yoktur. Bunları iframe veya shadow DOM sınırına alın, kendi CSP'lerini child-src ile verin ve yalnızca asgari alanları taşıyan bir postMessage sözleşmesi bırakın.
5. Şablon başına ayrı politika uygulayın. Giriş, checkout ve hesap sayfaları kısa allowlist, unsafe-inline yok, sabitlenmiş etiket alır. Pazarlama sayfaları gevşek politikayı alır. Patlama yarıçapı farkı tam olarak bu.
6. Reporting API'ye geçin. Report-To ve CSP Reporting, üretim ölçeğinde yapısal ve örneklenmiş ihlal verisi verir. Önce envanterde olmayan script'leri keşfetmek için, sonra politikayı ayarlamak için kullanın.
7. Tarayıcı tarafına bir tuzak tel koyun. Vendor'lardan önce yüklenen küçük bir first-party script, hassas saydığı form alanlarını anlık görüntüler ve allowlist dışı origin'lerden gelen beklenmedik submit dinleyicilerini, kopyalanmış düğümleri veya sendBeacon çağrılarını gözetler. Baypas edilebilir — yetkin saldıran gözlemciyi kaldırır — tam da bu yüzden sabitleme ve çıkış politikasının yerine değil, yanında durur.
8. Vendor değişim şartlarını sözleşmeye koyun. Değişim bildirim süresi, belgeli build provenance'sı, her yayın için SBOM ve denetim hakkı. Ticari kaldıraç, birinci başarısızlık biçimine ulaşan tek kaldıraçtır.

Test Kapsamı Açısından Ne Anlama Geliyor

Kapsam görüşmelerinde en çok tartışma yaratan kısım bu, o yüzden açık konuşalım.

Üçüncü parti script davranışı yetkili bir değerlendirme içinde test edilebilir ve çoğu zaman kazaen kapsam dışında bırakılır. Kendi sayfalarınızda şunları yapabilirsiniz: çalışan her şeyi saymak, sahibine bağlamak, neyin okunabilir olduğunu kontrol etmek, sabitlenip sabitlenmediğini doğrulamak, CSP ve cookie bayraklarını incelemek, ve uygulamanın özel sandığı bir DOM değerinin bir etiket tarafından reachable olduğuna zararsız bir kanıt üretmek. Yapamayacağınız şey vendor'a saldırmaktır: onların altyapısını, CDN'ini veya yönetim panelini yoklamak ayrı bir yazılı izin gerektirir.

Bu ayrımın bulgu bildiriminde pratik bir sonucu vardır. "Bir vendor ihlal edilebilir" bulgu değildir; yanlışlanamaz ve risk kaydında yeri vardır. "Bugün checkout sayfasında servis edilen script, kart sahibi adı alanını okuyabiliyor, hiçbir konfigürasyonunuzda geçmeyen bir adrese POST ediyor ve hiçbir şey bunu sabitlemiyor ya da izlemiyor" tekrarlanabilir kanıtı, iş etkisi ve çözümü olan bir bulgudur.

Faydalı bir kural: kapsam belgesi URL'lerden ve oturum açma seviyelerinden bahsediyor ama "bu URL'lerde yürüyen üçüncü parti kod"dan bahsetmiyorsa kapsam eksiktir. Test başlamadan önce ekletin — bu, neyi test edebildiğinizi değil, hangi kanıtı toplamanız gerektiğini değiştirir.

Hızlı Karar Tablosu

Sık Sorulan Sorular

Sıkı bir Content Security Policy üçüncü parti script ele geçirilmeyi durdurur mu?

Tek başına hayır. CSP hangi origin'lerin kod yürüteceğini kısıtlar; sizin zaten güvendiğiniz bir origin'den gelen düşmanca yük, onayınızla yürütülür. Nonce ve hash tabanlı politikalar, çalışma zamanında sonradan çekilen script'leri kapsamaz. Yine de yerini korur: allowlist'i mümkün olan en az script kaynağına indirin, bir raporlama ucu ekleyin ve şablon başına politika kullanarak oturum açmış sayfaları kamusal sayfalardan daha sıkı tutun.

Subresource Integrity vendor yayın yaptığında sitemi bozar mı?

Büyük olasılıkla evet — bu yüzden her yerde değil, seçici uygulanır. Sabitleme, tarayıcının kayıtlı hash'ten farklı bir etiketi yürütmeyi reddetmesi demektir; haber verilmemiş bir vendor deploy'u sizin tarafınızda bozuk bir özelliğe dönüşür. Pratik kalıp, kimlik doğrulama ve işlem sayfalarındaki etiketleri sabitlemek, bir fallback yolu tutmak ve sabitleme güncellemelerinin 04:00'te keşfedilmek yerine planlanması için vendor ile bir değişim bildirim kanalı müzakere etmektir.

Bir zafiyet tarayıcısı bu sınıf sorunu bulur mu?

Güvenilir biçimde hayır. Tarayıcılar sunucunuzun kendi isteklerine döndürdüğüne bakar; üçüncü parti etiketler koşullu, geç ve çoğunlukla yalnızca oturum açmış ya da coğrafyaya göre kapsanmış ziyaretçilere yüklenir. Oturumsuz ve kısa ömürlü bir tarayıcıyla yapılan tarama gecikmeli yüklemeleri hiç görmez, A/B bölümünün yalnızca bir dalını gözlemler. Gerçeği ortaya koymak gerçek tarayıcı, gerçek oturum ve zaman içinde tekrar gerektirir; bu tarama değil değerlendirme işidir.

Bu, ele geçirilmiş bir npm bağımlılığından nasıl farklı?

Başarısızlık alanından. npm bağımlılığı derleme zamanında çekilir, sürümlüdür, lockfile'ınızda görünür ve SBOM'unuzda yer alır; onu bulan kontroller tedarik zinciri taraması ve provenance'tır. Tarayıcı tarafı bir etiket ziyaretçi tarafından sayfa görüntüleme anında çekilir, sürümsüzdür, deponuzda yoktur ve vendor'un takviminde değişir; hiçbir derleme zamanı kontrolüne yakalanmaz. İkisi de ayrıcalıklı kod yoludur; yalnızca biri artifact'ınıza bakarak bulunabilir.

Penetrasyon testinde üçüncü parti script'leri test etmeli miyim?

Evet, ve teste başlamadan önce bunu kapsam belgesine yazılı olarak ekletin. Kendi sayfalarınızda çalışanı test etmek yetki dahilindedir. Vendor'un altyapısını test etmek, o vendor ayrıca yetki vermediği sürece değildir; o yüzden etkinliği upstream'e saldırmak etrafında değil, sahibine bağlama, veri erişilebilirliği, sabitleme ve izleme boşlukları etrafında kurgulayın. Spesifik bir script'i, tam olarak okuyabildiği alanı ve POST ettiği adresi adlandıran bulgu eyleme geçirilebilirdir; "vendor'lar ihlal edilebilir" diyen bulgu değildir.

Sonraki Adım

Politika tartışması yerine gerçeği istiyorsanız, en küçük faydalı etkinlik; oturum açılmış ve işlem gören şablonlarınızda bir çalışma zamanı script envanteri çıkarıp, sahibe bağlama, veri erişilebilirliği kanıtı ve etiket başına değişim tespit önerisi sunmaktır. Eresus Security bunu web uygulaması sızma testi kapsamında ve CSP tartışmasından önce cevaba ihtiyaç duyan ekipler için bağımsız bir kapsam olarak yürütür. Kanıt üretim biçimimiz için Eresus Guard sayfasına bakın, kapsamı konuşmak için bize ulaşın.