Üçüncü taraf script'leri sabitleyin, kısıtlayın veya kaldırın

Ödeme, giriş veya yönetim sayfanızdaki her üçüncü taraf script, sayfayı yükleyen kullanıcıyla aynı yetkilerle çalışır. Bu script'i sunan sunucu ele geçirilirse saldırgan da aynı yetkilere sahip olur, tıpkı XSS'te olduğu gibi. Çözüm, hangi script'lerin yüklendiğini bilmekle başlar. Ardından kaldırabildiklerinizi kaldırır, kalanları sabitler veya kısıtlarsınız.

Hassas sayfalarda neyin çalıştığını bilin

Üçüncü taraf JavaScript'e ilişkin OWASP cheat sheet üç riski sayar: istemci uygulamanızdaki değişiklikler üzerindeki kontrolü kaybetmek, istemci sistemlerinde rastgele kod çalıştırılması ve hassas bilgilerin üçüncü taraflara sızması. Örnekleri arasında 2018'deki Ticketmaster olayı ve ClearSky'ın ödeme verisi hırsızlığına dair Magecart araştırması yer alır.

Envanteri sayfa sayfa oluşturun; ödeme, giriş ve yönetim sayfalarıyla başlayın. Her script için URL'yi, iş tarafındaki sahibini, neden var olduğunu ve sayfaya nasıl geldiğini kaydedin. OWASP üç teslimat yolunu tarif eder: sayfaya yapıştırılmış tedarikçi kodu, tedarikçiyi işaret eden bir <script src> ve bir tag manager üzerinden dolaylı istek.

Tag manager en az görünür olanıdır. Birden fazla tedarikçiden script döndürebilir ve çalışanlar, kodunuza dokunmadan bir web arayüzü üzerinden neyin döndürüleceğini değiştirebilir. Değişiklikler bir sonraki sayfa yüklemesinde canlıya çıkar ve kod genellikle obfuscate edilmiştir.

HTML kaynağı bu script'leri göstermez. Geliştirici araçlarını açın, Network sekmesine geçin, ödeme ve giriş akışlarını baştan sona izleyin ve script sunan her host'u listeleyin.

Önce kaldırın, sonra kendi kopyanızı barındırın

Her kaydın sahibine, o script'in bu sayfada gerçekten bulunması gerekip gerekmediğini sorun. Bir giriş sayfasındaki veya yönetim panelindeki pazarlama etiketinin iyi bir gerekçesi nadiren olur.

Kalacak script'ler için OWASP, savunma olarak kendi sunucunuzda barındırmayı (in-house mirroring) önerir. İncelenmiş bir kopyayı kendiniz sunarsınız; böylece üçüncü bir taraf onu değiştiremez ve tedarikçi artık ziyaretçinin IP adresini, referrer bilgisini veya cookie'lerini almaz. Bunun bedeli bakım yüküdür: kopya, tedarikçinin düzeltmelerini kaçırır, dolayısıyla onu yeniden inceleme ve güncelleme işinin bir sahibi olmalıdır.

Terk edilmiş tedarikçiler ayrı bir sorundur. Tedarikçi battığı veya projeyi bıraktığı için script'i barındıran alan adının süresi dolarsa, biri bu alan adını yeniden kaydedip kötü amaçlı kod yayınlayabilir. Envanterinizde yer alan terk edilmiş bir tedarikçi başlı başına bir bulgudur.

Tuttuklarınızı Subresource Integrity ile sabitleyin

Subresource Integrity (SRI), sayfanın bir dosyanın eşleşmesi gereken hash değerini bildirmesini sağlar. Tarayıcı, script'i çalıştırmadan veya stil sayfasını uygulamadan önce indirilen dosyayı bu hash ile karşılaştırır; fark varsa ağ hatası döndürür. MDN'nin SRI rehberi hash üreten komutu verir:

cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A

Çıktının başına sha384- ekleyin ve elemente yerleştirin:

<script src="https://cdn.example.com/script.js"
  integrity="sha384-..."
  crossorigin="anonymous"></script>

İşaretlemenin birkaç gereksinimi vardır:

• crossorigin özniteliği zorunludur. Tarayıcı, no-cors isteklerinde SRI'yı reddeder; bu nedenle öznitelik olmayan bir etiket her zaman başarısız olur.
• CDN, Access-Control-Allow-Origin header'ı göndermelidir. Çoğu * gönderir.
• Birden fazla hash listeleyebilirsiniz. Tarayıcı yalnızca mevcut en güçlü algoritmaya ait hash'leri kullanır (artan sırayla SHA-256, SHA-384, SHA-512) ve herhangi biri eşleşirse dosyayı kabul eder; bu sayede bir yükseltme sırasında iki sürüme birden izin verebilirsiniz. W3C spesifikasyonu aynı davranışı tarif eder.

SRI, siz değiştirene kadar aynı kalan dosyalara uygundur. Tedarikçinin dilediği zaman düzenlediği bir script her düzenlemeden sonra doğrulamayı geçemez; tag manager container'ı da bu türden bir script'tir. Ona kimlerin yayın yapabileceğini kısıtlayın ve en hassas sayfalarınızdan uzak tutun.

Content Security Policy ile kısıtlayın

SRI, belirli bir dosyanın neyi içermesi gerektiğini söyler. Content Security Policy (CSP) ise script'lerin hangi kaynaklardan gelebileceğini belirler. MDN'nin CSP rehberi, onu yalnızca ana belgede değil, tüm yanıtlarda Content-Security-Policy header'ı ile iletmenizi söyler.

Hassas bir sayfa için başlangıç noktası, gerçekten kullandığınız host'ları listeler:

Content-Security-Policy: script-src 'self' cdn.example.com; object-src 'none'

Bir script-src veya default-src direktifi tanımlandığında, açıkça izin vermediğiniz sürece inline JavaScript engellenir. MDN, CSP'nin amacının büyük bölümünü boşa çıkardığı için 'unsafe-inline' kullanımından kaçınmanızı söyler. Inline script gerektiğinde nonce kullanın: her yanıt için üretilen, tahmin edilemeyen ve bir şablon tarafından eklenen bir değer. Statik sayfalar için MDN bunun yerine hash'leri önerir; bu durumda harici script'lerin de integrity özniteliğine ihtiyacı olur.

OWASP, tag manager container'ları özel JavaScript ve HTML çalıştırabildiği için data layer'ın bir sandbox olmadığını açıkça belirtir. Yayın erişimini kısıtlayın ve değişiklikleri uygulama kodu gibi inceleyin.

Siteyi bozmadan boşlukları bulun

Integrity-Policy header'ı, tarayıcının integrity özniteliği olmayan veya no-cors modunda yüklenen script'leri engellemesini sağlar. Önce yalnızca raporlama yapan sürümle başlayın:

Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity-endpoint)

Endpoint için eşleşen bir Reporting-Endpoints header'ı gerekir. İhlaller, engellenen URL'yi belirten integrity-violation türünde raporlar olarak gelir. Sabitlenmiş script'ler raporlardan düşer, bu yüzden raporlar tam bir script envanteri değildir.

Hiç rapor gelmediğinde MDN, engellemeyi kullanıcıyı etkileyen bir bozulma olmadan açmanın güvenli olduğunu söyler. Sabitleyemediğiniz bir tag manager container'ı rapor üretmeye devam eder; bu yüzden onu yükleyen sayfalar report-only modunda kalır. Sayfalarınızın gönderdiği header'ları HTTP header kontrol aracımızla inceleyebilirsiniz.

Nereden başlamalı

1. Ödeme, giriş ve yönetim sayfaları için envanteri Network sekmesinden oluşturun; her script için sahibini, amacını ve teslimat yolunu kaydedin.
2. Kimsenin gerekçelendiremediği kayıtları, özellikle giriş ve yönetim sayfalarındakileri kaldırın ve alan adı terk edilmiş görünen her tedarikçiyi işaretleyin.
3. Sahiplenip yeniden inceleyeceğiniz dosyaları kendi sunucunuzda barındırın. Tuttuğunuz her script'i sabitleyin: SHA-384 hash'leri üretin, integrity ve crossorigin="anonymous" ekleyin ve staging ortamında test edin.
4. Script'ler için Integrity-Policy-Report-Only yayına alın ve raporları okuyun. Integrity-Policy header'ını yalnızca sayfadaki her script'in integrity özniteliği olduğunda zorlayın; tag manager kullanan sayfaları report-only modunda tutun.
5. script-src ve object-src 'none' içeren bir Content-Security-Policy header'ını staging ortamında test edin, çünkü inline script'leri engeller. Tag manager'ınızda kimlerin yayın yapabileceğini kısıtlayın. Dışarıdan bir doğrulama için sızma testi bu sayfaları kapsayabilir.