Güvenlik sektöründe çalışıyorsanız, muhtemelen birkaç hafta önce kamuoyuna duyurulan polyfill.io olayını duymuşsunuzdur. Kaç web sitesinin etkilendiğini tam olarak bilmiyoruz ancak Cloudflare CEO’su Matthew Prince’in bir tweetine göre 110.000 ile birkaç milyon arasında büyük bir penceremiz var gibi görünüyor.
Etkilenen kullanıcılar bir spor bahisleri web sitesine yönlendiriliyordu ve açık olan şey bunun çok daha kötü olabileceğiydi. Bunun nedeni, bir saldırgan kodunu herhangi bir kısıtlama olmaksızın herhangi bir web sitesinde çalıştırdığında, herhangi bir hassas verinin toplu bir şekilde toplanmasını sağlayabilmesidir. Buna Kişisel Tanımlayıcı Bilgiler (PII), ödeme verileri, Korunan Sağlık Bilgileri (PHI) vb. dahildir – normalde web sitesi tarafından manipüle edilir. Ancak hepsi bu kadar değil. Saldırganlar web sayfası DOM’unu bozabilir, kullanıcının gördüklerini değiştirebilir, kullanıcıdan daha fazla bilgi isteyebilir veya kimlik bilgilerinin ve paralarının çalınabileceği kimlik avı web sitelerine yönlendirebilir.
Şimdi bunu yüz binlerce veya milyonlarca web sitesindeki kullanıcı sayısıyla çarpın. Neyse ki, bu son örnekte Namecheap, insanların ve kamuoyunun baskısı talep ettikten sonra alan adını kaldırmaya karar verdi. Ve şimdi, herkes bu özel olaydan güvende (evet, gerçekten istiyorsanız hala o spor bahisleri web sitesini ziyaret edebilirsiniz!). Daha önce de belirttiğim gibi, bu saldırıyı ortaya çıkarmak için gereken süreyi düşündüğünüzde, dolandırıcıya binlerce hatta milyonlarca kredi kartını dolandırmak için yeterince büyük bir pencere vermiş olurdu. Ya da milyonlarca kişiden kişisel verileri sızdırmak için yeterince zaman. Bunların hepsi saldırganın yatırımını kat kat geri öderdi (sokakta alan adı ve GitHub deposunun 1 milyon dolara işlem gördüğü söyleniyor).
Hafif gerçek sonuçlara rağmen, saldırının potansiyel kapsamını düşünürseniz, kötüydü. Yeni olduğu için değil, olmadığı için. Neredeyse her yıl kötü amaçlı yazılımlarla tehlikeye atılan büyük bir node.js paketimiz oluyor. Örneğin, 2021’de: saldırganlar geliştiricinin hesabını ele geçirmeyi başardı ve ua-parser-js NPM paketine kötü amaçlı kod enjekte etti. Buna bir kripto madencisi ve parola çalma kodu dahildi. 2018’deki başka bir örnekte, yaygın olarak kullanılan bir NPM paketi olan event-stream tehlikeye atıldı ve bu durumda, bu bağımlılığı kullanan belirli Bitcoin cüzdanları boşaltıldı. Kötüydü çünkü bir kez daha web’in tedarik zinciri saldırılarına karşı ne kadar savunmasız olduğunu gösterdi.
polyfill.io olayı, XZ lib veya benzeri işlevsiz alan tabanlı saldırılar gibi, saldırganların çok fazla uğraşmadan binlerce uygulamada kötü amaçlı yazılım çalıştırmak için üçüncü taraf bileşenlerinin kontrolünü kasıtlı olarak ele geçirmeye çalıştıkları bir eğilimi gösteriyor. Sırasıyla, bu projeleri satın almayı teklif ediyorlar, mevcut bakımcıları kontrolü onlara devretmeye kandırıyorlar veya bugün web’i etkileyen uygun kod hijyeninin eksikliğinden faydalanıyorlar.
İlk bakışta, sorunu ele almanın bir yolunun bu projelerin kime ait olduğunun görünürlüğünü önemli ölçüde artırmak ve sahiplik değişiklikleri konusunda uyarılar sağlamak olduğunu iddia edebiliriz. Ya da, bunu yalnızca ilgili alan adları için yaparak, alan adının sahibi olanın projeye sahip olduğunu varsayarak daha da basit hale getirebiliriz. Bu, bu alan adlarında anonim WHOIS kayıtlarının yasaklanmasıyla başlayabilir ve alan adı sahibinin kimliğinin uygun şekilde doğrulanmasıyla sona erebilir. Ancak günün sonunda, yeni sahiplerin gündemini bilmediğimiz için yine de savunmasız olacağız ve birçok güvenlik uzmanının bildiği gibi, yalnızca itibara dayalı güvenlik başarısızlığa mahkumdur (son zamanlarda XZ olayında da kanıtlandığı gibi). Polyfill.io olayıyla ilgili sorun, insanlardan binlerce web sitesi tarafından kullanılan bileşenleri satmamalarını isteyerek de çözülemez çünkü bunun daha fazlası olacak.
Sorun her web sitesi geliştiricisi tarafından ayrı ayrı çözülmelidir. Geliştiriciler iyi bir güvenlik mimarisi seçmeli, maruz kalmak istedikleri yazılım bileşenlerini dikkatlice seçmeli ve bu bileşenlerden gelen herhangi bir etkinin uygun güvenlik izolasyonuyla zayıflatıldığından emin olmalıdır.
Bunu geçmişte konuşmuştuk, önce son 20 yılın web izolasyon özelliklerine bir göz attık. Oradan, web’in yerel izolasyon mekanizmaları sunduğu sonucuna vardık. Ancak bunları doğru şekilde nasıl kullanacağınızı bilmek her zaman basit değildir. Aslında, çoğu zaman insanlar işleri yoluna koymak için bu mekanizmaları gevşetir ve daha sıkı güvenlikten ödün verirler. Daha sonra, insanlara zaten bildikleri şeyi söyleyerek odadaki fili ele aldık: tek başına yama yapmak işe yaramıyor ve bunun iyi bir güvenlik mimarisi, saldırı yüzeyi azaltma ve uygun izolasyon mekanizmalarıyla tamamlanması gerekiyor.
Peki, bunu yapmak için gerekli araçlara ve bilgiye sahipsek, neden başarısız olmaya devam ediyoruz? Bunun nedeni, bunu kaç kez söylemiş olursak olalım, güvenliğin hala sonradan akla gelen bir şey olması ve bunu doğru yapmanın tek yolunun en başından itibaren planlamak olmasıdır. Web uygulamaları, yalnızca taşınabilir oldukları için değil, aynı zamanda en hızlı ve en ucuz şekilde oluşturulabildikleri için insanlara yazılım sunmanın standart yolu haline geldi. Ve bunun arkasındaki temel neden, kasıtlı olarak veya olmayarak, doğalarının son derece birleştirilebilir olmasıdır. Bunu kim bulduysa
Source link