Bir CDN üzerinden teslim edilen JavaScript dosyalarımın değiştirilmediğinden nasıl emin olabilirim?

88

Bazı JavaScript dosyalarının bir CDN'de barındırılacağı bir senaryo üzerinde çalışıyorum. Bir mekanizmaya sahip olmak istiyorum, böylece bu dosyalar kullanıcı tarafından indirildiğinde, dosyaların tahrif edilmediğinden ve gerçekten de belirtilen CDN'den geldiklerinden emin olabilirim.

SSL kullanıyorsam görevin çok kolay olduğunu anlıyorum, ancak yine de, SSL olmadan HTTP'de bile doğru dosyaların sunulmasını sağlamak istiyorum.

Arama yapabildiğim kadarıyla, platformlar arasında desteklenen JavaScript dosyaları için dijital imza gibi mevcut bir mekanizma yok. Belki gerekli değildir?

JavaScript dosyalarının yazarını doğrulamak için tarayıcılarda yerleşik bir yöntem var mı? Bunu güvenli bir şekilde yapmak için yapabileceğim herhangi bir şey var mı?

javascript code-signing

— baba26
kaynak

13

Bu soruyu ilginç bulsam da konu dışı değil mi?

— evolutionxbox

20

neden dosyaları http üzerinde sunuyorsunuz?

— njzk2

12

"Ama neden böyle bir mekanizma yok?" Çünkü gerçekten zor . Verileriniz sunucunuzdan ayrıldıktan sonra kadeh kaldırır. HTTPS yardımcı olur, ancak düz bir HTTP bağlantısı ise, herhangi bir doğrulama başarısız olabilir (veya daha doğrusu geçebilir). Bir MITM saldırısı, tarayıcı beklentileri karşılamadan önce beklenen imzanızı ve / veya size sağlanan şeyin imzasını değiştirebilir. Bu nedenle, kullanıcı bir miktar yük aldığında, tamamen güvenli kabul edilir ... bunun zorunlu olmadığı durumlarda.

— VLAZ 01

4

"Ama neden böyle bir mekanizma yok?" Çünkü HTTPS'de halihazırda ucuz, etkili ve geniş çapta uygulanabilir bir çözüm var.

— Kevin Krumwiede

9

Bu, muhtemelen dosyaları güvenli bir şekilde sunmakla ilgili olduğundan, muhtemelen ServerFault veya Güvenlik'te olmalıdır ve programlamayla herhangi bir ilişki, söz konusu dosyalar kaynak kodunu temsil ettiği sürece yalnızca teğetseldir.

— underscore_d

140

Nitekim, bunun gibi bir özellik şu anda Subresource Integrity adı altında tasarlanmaktadır . Etiketin niteliğine bakın . integrity<script> Henüz yönetim kurulu tarafından tam olarak benimsenmemiş olsa da , tam da bu amacı yerine getiriyor.

integrity

Bir kullanıcı aracısının, getirilen bir kaynağın beklenmedik manipülasyon olmadan teslim edildiğini doğrulamak için kullanabileceği satır içi meta verileri içerir. Bkz. Alt Kaynak Bütünlüğü.

Kaynak

Alt Kaynak Bütünlüğü (SRI), tarayıcıların aldıkları dosyaların (örneğin bir CDN'den) beklenmedik bir manipülasyon olmadan teslim edildiğini doğrulamasını sağlayan bir güvenlik özelliğidir. Getirilen bir dosyanın eşleşmesi gereken bir kriptografik karma sağlamanıza izin vererek çalışır.

Kaynak

Misal:

<script src="https://example.com/example-framework.js"
    integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
    crossorigin="anonymous"></script>

Ancak, kaynaklarınızı düz HTTP yoluyla aktarıyorsanız, bunun sizi Ortadaki Adam saldırılarına karşı korumayacağını unutmayın . Bu durumda, karma kod, saldırgan tarafından sahtekarlık yaparak manipüle edilen komut dosyalarına karşı savunmayı işe yaramaz hale getirebilir.

Bu nedenle, yukarıda açıklanan güvenlik önlemlerine ek olarak her zaman düz HTTP yerine güvenli HTTPS bağlantıları kullanmalısınız.

— Timo
kaynak

9

OP'nin HTML'lerini ve varlık dosyalarını HTTP'de göndermeyi planladığını varsayarsak, bütünlük kontrolünün kolayca sahte yapılabileceğini belirtmekte fayda var. Siteleri HTTPS ise ve varlıkları HTTP aracılığıyla sunmak istiyorlarsa, çoğu tarayıcı bundan hoşlanmayacak ve HTTP varlıklarını sessizce görmezden gelecektir.

— MonkeyZeus

3

@MonkeyZeus Bu yalnızca bir MITM saldırısı durumunda veya kendi sunucumuzun güvenliği ihlal edildiğinde doğru olur, değil mi? Anladığım kadarıyla, soru açıkça, tehlikeye atılmış bir CDN'ye karşı nasıl savunulacağını soruyor.

— Timo

10

@TimoSta Kesinlikle! Bu kontroller yerinde olmadan, örneğin, bir komut dosyasını eklerseniz, HTTPS üzerinden erişilip erişilmediğine bakılmaksızın, https://code.jquery.com/güvenliği ihlal eden herkes code.jquery.comsitenizi XSS yapabilir code.jquery.com. Bu kontroller uygulandığında, saldırgan yalnızca komut dosyalarının yüklenmesini engelleyebilir, kötü amaçlı komut dosyalarının yerine geçemez.

— Ajedi32

1

@MonkeyZeus Cevabıma endişelerinizi belirten bir not ekledim. İfadeye katılıyor musunuz?

— Timo

1

@TimoSta Çok güzel, beğendim! btw, daha ilk

— yorumumu göndermeden

36

Alt kaynak bütünlüğü kontrollerini arıyorsunuz .

Örneğin, jQuery CDN pasajı şu şekildedir:

<script src="https://code.jquery.com/jquery-3.1.0.js"
        integrity="sha256-slogkvB1K3VOkzAI8QITxV3VzpOnkeNVsKvtkYLMjfk="
        crossorigin="anonymous"></script>

— Brian
kaynak

2

Tamamen işe yaramaz çünkü bir saldırgan, indirmekte olduğunuz komut dosyasını değiştirirken aynı zamanda bütünlük alanını değiştirebilir.

— Orbit'te Hafiflik Yarışları

15

@LightnessRacesinOrbit: HTTPS üzerinden erişilen ancak kontrol etmeyen kendi etki alanınızı kontrol ediyorsanız, hayır code.jquery.com. Bu sizi tehlikeden koruyabilir code.jquery.com.

— SilverlightFox

2

@SilverlightFox: Tamam, MITM saldırılarına karşı tamamen işe yaramaz *

— Orbit'te Hafiflik Yarışları

@LightnessRacesinOrbit Evet. Yine de çok yararlı ve bu saldırıyı önleyebilirdi, örneğin: bleepingcomputer.com/news/security/…

— Adrian Mouat

6

Sorumluluk Reddi: Her zaman olduğu gibi, bu mekanizmaların yalnızca https kullanırken herhangi bir işe yarayacağını düşünmelisiniz, çünkü bunlar http ile MitM aracılığıyla kolayca devre dışı bırakılabilir.

Yukarıdaki cevaplardaki mekanizmaya ek olarak , ana sayfadaki içerik-güvenlik politikası http yanıt başlıklarını da kullanabilirsiniz .

http://www.html5rocks.com/en/tutorials/security/content-security-policy/

İçerik Güvenliği Politikası: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng ='

Burada dikkat edilmesi gereken birkaç nokta var. Sha * - öneki, karmayı oluşturmak için kullanılan algoritmayı belirtir. Yukarıdaki örnekte sha256- kullanılmıştır. CSP ayrıca sha384 ve sha512'yi destekler. Karma oluştururken etiketleri dahil etmeyin. Baştaki veya sondaki boşluklar dahil olmak üzere büyük harf kullanımı ve boşluk da önemlidir.

Chrome 40 veya sonraki bir sürümünü kullanarak DevTools'u açıp sayfanızı yeniden yükleyebilirsiniz. Konsol sekmesi, satır içi komut dosyalarınızın her biri için doğru sha256 hash değerine sahip hata mesajlarını içerecektir.

Bu mekanizma epeydir ortalıkta, bu yüzden tarayıcı desteği muhtemelen oldukça iyi, kontrol ettiğinizden emin olun.

Ayrıca, uyumlu olmayan eski tarayıcıların güvensiz olmadığından emin olmak istiyorsanız, sayfanın üst kısmına politika tarafından izin verilmeyen bir zaman uyumlu yeniden yönlendirme komut dosyası ekleyebilirsiniz.

— Fabio Beltramini
kaynak

epeydir ortalıkta, ancak tarayıcı desteği pek iyi değil. caniuse.com/subresource-integrity

— Sp0T

@ Sp0t - Alt kaynak bütünlüğü (bağlantınızın ne hakkında olduğu) diğer yanıtlardaki mekanizmadır. Cevabım, çok daha iyi desteği olan içerik güvenliği politikası ile ilgili

— Fabio Beltramini

3

Bu tür bir imzalamanın ne yapıp ne yapamayacağına dair önemli bir nokta var. Bu olabilir birisi kodunuzu değiştirir ettiği varsayımsal saldırılardan kullanıcıyı korur. O olamaz kodunuzu yürütülmektedir kod olduğunu sitenizi sağlamak. Başka bir deyişle, sitenize istemciden gelen hiçbir şeye hala güvenemezsiniz.

— ddyer
kaynak

2

Düşman modeliniz, bir saldırganın JavaScript dosyalarını CDN'den teslim edilirken değiştirmesine izin veriyorsa, rakip modeliniz, bir saldırganın, herhangi bir doğrulama girişimini kaldırmak, kaynak adresini değiştirmek için teslim edilirken yönlendiren kaynağı değiştirmesine izin verir. CDN ve / veya JavaScript referansını tamamen kaldırmak için.

Ve uygulamanızın, kullanıcının çözücüsünün HTTP istekleri (veya doğrulanmış bir güven zinciri olmayan başka bir mekanizma) aracılığıyla CDN'ye doğru bir şekilde çözülüp çözülmediğini nasıl belirleyebileceğine dair solucanlar kutusunu açmayalım.

/ etc / hosts:

#  ...
1.2.3.4    vile-pirates.org    trustworthy.cdn
#  ...

— Eric Towers
kaynak

2

İlk cümle açıkça doğru değil. Ya yönlendiren sayfa HTTPS üzerinden ve JavaScript dosyası HTTP-not-S üzerinden yüklenirse?

— user253751

Ya da CDN'nin güvenliği ihlal edilmişse, ancak kendi sunucunuz değilse?

— Ajedi32

@immibis: OP'nin böyle bir senaryo önerecek kadar mantıksız olmadığını varsaymayı seçiyorum.

— Eric Towers

1

@immibis Tarayıcıların genellikle HTTPS sayfalarının HTTP üzerinden JS yüklemesine izin vermemesinin nedeni bu değil mi?

— Barmar

1

@immibis Tarayıcılar buna izin vermediği için mümkün olmayan bir durumu iyileştirdiğini söylüyordum.

— Barmar

1

Bunu Subresource Integrity ile sağlayabilirsiniz. Birçok genel CDN, CDN web sitelerinde sunulan gömülebilir koda SRI hash'leri içerir. Örneğin, PageCDN'de, jQuery CDN sayfasındaki jquery dosyasına tıkladığınızda, aşağıdaki gibi URL'yi kopyalama veya SRI hash içeren komut dosyası etiketini kullanma seçeneğine sahip olursunuz:

<script src="https://pagecdn.io/lib/jquery/3.4.1/jquery.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script>

Sayfa yüklenirken, tarayıcı bu kaynak için bir istek yayınlayacak ve talebin tamamlanması üzerine alınan dosyanın karmasını komut dosyası etiketinde bütünlük değeri olarak verilenle eşleştirecektir. Her iki karma da eşleşmezse, tarayıcı jquery dosyasını atacaktır.

Şu anda bu özellik, dünya çapındaki tarayıcıların% 91'i tarafından desteklenmektedir. Caniuse hakkında daha fazla ayrıntı .

— 5377037
kaynak