Alt Kaynak Bütünlüğünü Anlama

Daha önce bir JavaScript kitaplığının CDN tarafından barındırılan bir sürümünü kullandıysanız, komut dosyası etiketinde garip görünen bir integrity özniteliği fark etmiş olabilirsiniz. Bu öznitelik, görünüşte sonsuz alfasayısal önemsiz şeyler içerir ve bunları daha temiz kod arayışında çıkarmanız cazip gelebilir.

Tüm bu önemsiz şeyler aslında sitenizi belirli türdeki saldırı ve tavizlere karşı savunmaya yardımcı olabilecek Alt Kaynak Bütünlüğü (SRI) adı verilen gerçekten yararlı bir güvenlik özelliğidir. Bu makalede, SRI'nin ne olduğuna, sizi korumaya nasıl yardımcı olabileceğine ve onu yalnızca CDN'lerde barındırılan dosyalar için değil, kendi projelerinizde nasıl kullanmaya başlayabileceğinize bir göz atacağız.

Biraz Tarih

JavaScript'in HTML ve CSS'nin çok daha fakir kuzeni olduğu günlerde, komut dosyalarımızın web sitelerimiz için bir saldırı vektörü olarak nasıl kullanılabileceği hakkında çok fazla düşünmemize gerek yoktu. Çoğu site, kendi barındırma altyapımızda bir yerde tek bir fiziksel sunucuda barındırıldı ve en iyi güvenlik uygulamaları söz konusu olduğunda savunmayı düşündüğümüz sunucuydu.

Tarayıcılar daha yetenekli hale geldikçe ve ağ bağlantıları daha da şişmanladıkça, giderek daha fazla JavaScript kullanmaya başladık ve sonunda yeniden kullanılabilir JavaScript kitaplıkları ortaya çıkmaya başladı. O ilk günlerde script.aculo.us, Prototype ve sonunda jQuery gibi kütüphaneler, sayfalarına daha fazla etkileşim eklemek isteyen geliştiriciler arasında benimsenmeye başladı.

Bu eklenen kitaplıklar ve sonraki eklentilerle birlikte sayfa ağırlığı da arttı ve çok geçmeden ön uç performansı hakkında ciddi şekilde düşünmeye başladık. Daha önce dev şirketlerin rezervi olan İçerik Dağıtım Ağları (CDN'ler) gibi kaynaklar, gündelik halk tarafından hızlı web siteleri inşa etmek için yaygınlaşıyordu.

Yol boyunca, bazı parlak kıvılcım, sitelerin hepsinin ortak kitaplıkların kendi kopyalarını (en son jQuery gibi şeyler) istediğini fark etti ve bu kitaplıkların her site tarafından kullanılabilecek ortak bir CDN sürümü olsaydı, kullanıcı bunu yapmazdı. Aynı dosyayı indirmeye devam etmeniz gerekiyor. Dosyayı kullanan ilk site için isabet alırlardı, ancak daha sonra yerel tarayıcı önbelleklerine otururdu ve sonraki her site için indirmeler atlanabilirdi. Dahi!

Bu nedenle, jsdelivr.com gibi URL'leri kullanan favori kitaplıklarınız için CDN bağlantıları göreceksiniz - kullanıcılarının performans avantajlarını görmeleri için dosyaları barındırmak için ortak bir CDN kullanıyorlar.

Ne Yanlış Gidebilir?

Bu, çalışmak için iyi ve pratik bir yol olmaya devam ediyor, ancak saldırı için potansiyel bir vektör sunuyor. 2012 olduğunu ve herkesin yepyeni jQuery 1.8'i kullandığını hayal edelim. Geleneksel yöntemlerle, herkesin kendi sunucularında kendi web sitelerinin bir parçası olarak barındırılan kendi jQuery 1.8 dosyası olurdu.

Bir tür kötü aktör olsaydınız - bir tür jQuery tabanlı Hamburglar gibi - ve kendi kötü kazançlarınız için kütüphaneyi hacklemenin sinsi bir yolunu bulmuş olsaydınız, her web sitesini ayrı ayrı hedeflemeniz ve sunucularını tehlikeye atmanız gerekirdi. herhangi bir etki. Bu çok çaba.

Ancak herkes ortak bir CDN'den yüklenen jQuery'yi kullandığı için işler şimdi böyle değil. Ve herkes derken yüzlerce web sayfasını kastetmiyorum. Milyonlarca web sayfasını kastediyorum. Birdenbire bu tek dosya, karanlık bilgisayar korsanımız için çok çekici bir hedef haline geldi. Eğer bu tek dosyadan ödün verebilirlerse, dünya çapında milyonlarca web sayfasında çok hızlı bir şekilde kod çalıştırabilirler.

Bu kodun ne olduğu önemli değil. Sayfaları tahrif etmek için bir şaka olabilir, şifrelerinizi çalmak için bir kod olabilir, kripto para birimi madenciliği yapmak için bir kod olabilir veya sizi web'de takip etmek ve bir pazarlama profili oluşturmak için sinsi izleyiciler olabilir. Önemli olan, geliştiricinin bir sayfaya eklediği masum dosyanın değiştirilmiş olması ve artık sitenizin bir parçası olarak çalışan bazı kötü JavaScript'leriniz olmasıdır. Bu büyük bir problem.

Alt Kaynak Bütünlüğünü Girin

Saatleri geri almak ve kodu kullanmanın kullanışlı bir yolunu terk etmek yerine, SRI, üstüne basit bir güvenlik düzeyi ekleyen bir çözümdür. SRI ve integrity özniteliğinin yaptığı, bir sayfaya bağladığınız dosyanın asla değişmemesini sağlamaktır. Ve eğer değişirse, tarayıcı bunu reddedecektir.

Kodun değişmediğini kontrol etmek, bilgisayar bilimlerinde çok eski bir sorundur ve neyse ki çok iyi kurulmuş bazı çözümleri vardır. SRI, en basit dosya karmasını benimseme konusunda iyi bir iş çıkarıyor.

Dosya karma işlemi, bir dosyayı alma ve onu karma veya sağlama toplamı olarak bilinen kısa bir dize temsiline indirgeyen bir algoritma aracılığıyla çalıştırma işlemidir. Yabani otlara girmeden, süreç ya tekrarlanabilir ya da tersine çevrilebilir, o kadar ki, bir başkasına hash ile birlikte bir dosya verecek olsaydınız, ikisi eşleşip eşleşmediğini kontrol etmek için aynı algoritmayı çalıştırabilirlerdi. Dosya değişirse veya karma değişirse, artık bir eşleşme yoktur ve bir şeylerin yanlış olduğunu bilirsiniz ve dosyaya güvenmemeniz gerekir.

SRI kullanırken, web sayfanız karmayı tutar ve sunucu (CDN veya herhangi bir yer) dosyayı tutar. Tarayıcı dosyayı indirir, ardından integrity özelliğindeki karma ile eşleştiğinden emin olmak için hızlı bir şekilde hesaplar. Eşleşirse dosya kullanılır, değilse engellenir.

Denemek

Bugün bir Bootstrap sürümüne CDN bağlantısı almak için getbootstrap.com , bana şuna benzeyen bir etiket verilir:

 <script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>

src özniteliğinin alıştığımız gibi olduğunu ve integrity özniteliğinin şu anda karma olarak bildiğimiz şeyi tuttuğunu görebilirsiniz.

Hash aslında iki kısımdır. İlki, hangi karma algoritmanın kullanılacağını bildiren bir önektir. Bu durumda, sha384 . Bunu bir tire ve ardından base64 ile kodlanmış hash'in kendisi takip eder.

Görüntüler gibi satır içi dosyaları sayfalara kodlamanın bir yolu olarak base64 aşina olabilirsiniz. Bu bir kriptografik süreç değil — sadece, potansiyel olarak karmaşık verileri düzgün bir şekilde ASCII'ye çevirecek şekilde kodlamanın hızlı ve kullanışlı bir yolu. Bu yüzden internette çok kullanılıyor.

Bunu gören tarayıcı, bootstrap.min.js dosyasını indirecektir. Yürütmeden önce, hash'in kodunu base64 çözecek ve ardından hash'in henüz indirdiği dosyayla eşleştiğini doğrulamak için sha384 hashing algoritmasını kullanacak. Eşleşirse, dosya yürütülür.

Bunu, bu etiketi bir sayfaya koyarak ve ardından dosyanın yüklendiğini görmek için tarayıcı araçlarımda Ağ sekmesine çevirerek test edebilirim.

bootstrap.min.js dosyasının (ve ayrıca ihtiyaç duyduğu jQuery dosyasının) başarıyla yüklendiğini görebiliyorum.

Hash'i yanlış olduğunu bildiğim bir şey olacak şekilde güncellersem ne olacağını görelim.

 <script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="sha384-SmashingMagazineIsCoolForCats" crossorigin="anonymous"></script> 

Gördüğünüz gibi sayfamda belirttiğim hash artık dosya ile eşleşmediği için dosya bloke oluyor.

Kendi Projelerinizde SRI Kullanmak

Bir CDN'deki kitaplıklar için bu yeteneğe sahip olmak harikadır ve bir integrity özniteliğine sahip gömülü bir dosya kullanma seçeneğini görürseniz, kesinlikle bu seçeneği tercih etmelisiniz. Ama CDN'lerdeki büyük projelerle sınırlı değil, bunu kendi siteleriniz için kendiniz de kullanabilirsiniz.

Bir bilgisayar korsanının sitenizdeki yalnızca birkaç dosyaya erişmeyi başardığı bir senaryo hayal etmek hiç de zor değil. Sanırım çoğumuz bir noktada bir WordPress sitesine sahip olan ve orada olduğunu bile fark etmedikleri bir sürü kötü önemsiz şeyle tehlikeye atılmış bir müşteri, meslektaş veya arkadaş gördük.

SRI sizi bundan da koruyabilir. Kendi dosyalarınız için bütünlük karmaları oluşturursanız, tıpkı uzaktan barındırılan bir dosyada olduğu gibi sitenizin tüm değişiklikleri reddetmesini sağlayabilirsiniz.

Hash Oluşturma

Beklediğiniz gibi, bir dosya için karma oluşturmak için bilgisayarınızın terminalinde bazı komutları çalıştırabilirsiniz. Bunun nasıl yapılacağına ilişkin bu örnek, MDN Alt Kaynak Bütünlüğü sayfasından gelir:

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

Bu, FILENAME.js içeriğini almak ve bunu, sha384 kullanarak bir özet oluşturmak için openssl'ye girdi olarak geçirmek ve ardından sonucu base64 kodlamak için başka bir openssl komutuna girdi olarak openssl . Bu sadece karmaşık ve anlaşılmaz olmakla kalmıyor, aynı zamanda JavaScript dosyanız her değiştiğinde elle yapmak isteyeceğiniz türden bir şey de değil.

Daha da yararlısı, bunu bir şekilde sitenizin inşa sürecine entegre etmek isteyeceksiniz ve tahmin edeceğiniz gibi orada birçok hazır seçenek var. Kesin uygulama, projenize göre çılgınca değişecektir, ancak işte bazı yapı taşları.

Sitelerinizi oluşturmak için Gulp kullanıyorsanız, dosyalarınızın ve karmalarının bir listesini içeren bir JSON dosyası çıkaran gulp-sri vardır. Daha sonra bunu sitenizde kullanabilirsiniz. Örneğin, dinamik olarak oluşturulmuş bir site için, bu dosyayı okumak ve gerektiğinde şablonlarınıza karmaları eklemek için bir şablon eklentisi oluşturabilirsiniz.

Hâlâ Gulp'taysanız ancak statik bir siteniz (veya statik olarak oluşturulmuş bir siteniz) varsa, HTML sayfalarınızda gerçekten çalışacak ve gerektiğinde çok kullanışlı olan karma eklemek için sayfaları değiştirecek olan gulp-sri-hash kullanabilirsiniz.

Webpack kullanıyorsanız, gerçek Webpack stilinde herhangi bir insanın beklediğinden daha karmaşık olan, ancak işe yarıyor gibi görünen web sayfası-alt kaynak-bütünlüğü vardır.

Gidon şablonlama motorunu kullananlar için, kullanabileceğiniz seçenekler var gibi görünüyor ve oluşturma süreciniz yalnızca temel JavaScript ise, orada da basit çözümler var.

WordPress gibi bir CMS kullanıyorsanız, kendim denememiş olmama rağmen bunu kolaylaştıran bir eklenti buldum. SRI veya Alt Kaynak Bütünlüğü ile kendi tercih ettiğiniz platform için arama yapmak, muhtemelen sizi doğru yöne yönlendirecektir.

Esasen, JavaScript dosyalarınız küçültüldükten sonra karma işleminizi bağlamak ve ardından bu karma değeri, sisteminizin herhangi bir parçasının <script> etiketlerini verdiği herhangi bir şekilde kullanılabilir hale getirmek istiyorsunuz. Web platformunun harikalarından biri, teknik olarak çok çeşitli olması, ancak bu ne yazık ki size iyi uygulama talimatları veremememe neden oluyor!

Dikkat Edilmesi Gereken Diğer Şeyler

Bu makalede, JavaScript dosyalarından çok bahsettim çünkü hack saldırılarına karşı savunmanın gerçekten en mantıklı olduğu yer burası. SRI, CSS ile de çalışır ve böylece onu orada tam olarak aynı şekilde kullanabilirsiniz. Kötü niyetli CSS riski çok daha düşüktür, ancak bir siteyi tahrif etme potansiyeli hala mevcuttur ve kim bilir hangi tarayıcı hatalarının CSS'nin sitenizi istemeden bir bilgisayar korsanına maruz bırakmasına da yol açabileceğini bilir. Yani orada da SRI kullanmak işe yarıyor.

Yapabileceğiniz bir başka ilginç şey de, sayfanızdaki herhangi bir komut dosyasının (veya stillerin) SRI kullanması gerektiğini ve elbette SRI'nin doğrulaması gerektiğini belirtmek için bir İçerik Güvenliği Politikası kullanmaktır.

 Content-Security-Policy: require-sri-for script;

Bu, SRI'nın her zaman kullanılmasını sağlamanın bir yoludur; bu, işlerin nasıl yapılacağına tam olarak hakim olan veya olmayan birden fazla ekip üyesi tarafından üzerinde çalışılan sitelerde faydalı olabilir. Yine, bununla ilgili daha fazla bilgi edinmek için iyi bir yer, Alt Kaynak Bütünlüğü için her zaman harika MDN belgeleridir.

Bahsetmeye değer son şey, SRI için tarayıcı desteği. Modern tarayıcılardaki destek, ana istisna olan Internet Explorer olmak üzere geniştir. Bununla birlikte, spesifikasyonun uygulanmış olduğu geriye dönük uyumlu yol nedeniyle, hemen kullanılması güvenlidir. integrity özniteliğini anlayan tarayıcılar, hash'i kullanacak ve bütünlüğü kontrol edecek ve eski tarayıcılar her zaman olduğu gibi çalışmaya devam edecek. Elbette, ek korumayı bu eski tarayıcılarda alamayacaksınız, ancak destek sunan tarayıcılarda alacaksınız.

Çözüm

Yalnızca integrity özniteliklerindeki bu tuhaf karmaların ne yaptığını değil, bunları web sitemizdeki belirli saldırı türlerine karşı savunmak için nasıl kullanabileceğimizi de gördük. Elbette, sitelerimizi her tür istismara karşı savunacak tek bir gümüş kurşun yoktur, ancak Alt Kaynak Bütünlüğü zincirde gerçekten yararlı bir araçtır.

Bir güvenlik açığından yararlanmak, genellikle birden fazla küçük parçayı sıraya koymakla ilgilidir. A yerindeyse ve B'yi gerçekleştirebilirseniz, C'deki bir hata D'yi mümkün kılar. SRI gibi tarayıcı özellikleri, işleri biraz daha bağlamanın ve potansiyel olarak bu zinciri kırmanın ve bir bilgisayar korsanının istediklerini elde etmesini önlemenin iyi bir yolunu sunar. Dahası, onu inşa sürecinize veya CMS'nize entegre edebilirseniz, bu bir kez kurabilmeniz ve ardından unutabilmeniz gereken bir şeydir ve size her gün rahatsızlık vermez.

Bu nedenle, Alt Kaynak Bütünlüğüne ciddi bir şekilde bakmanızı ve mümkünse sitelerinize uygulamanızı gerçekten tavsiye ederim.