Hayal kırıklığım her zaman yüksek çünkü daha yeni oldu. CVE-2022–29622: Güvenlik Açığı Analizi başlıklı önceki analizimi okuduysanız , neden bahsettiğimden şüphelenebilirsiniz. Aynı hikaye, farklı kurban. Ancak bu durumda tarihler önemlidir. Önceki zarar görmezlik analizim 2022'den, bugün 2018'den başka bir konuyu analiz edeceğim.

"Neden 2018'den bir şeyle uğraşmak zorundasın?" diye sorabilirsiniz. Mükemmel soru! Çünkü yakın zamanda, Sonatype'ın OSS Dizininden güvenlik açığı bilgilerini çekmek için Dependency Track'i etkinleştirdim.

Bugün, savunmasız bileşenlerimiz olup olmadığını görmek ve varsa iyileştirme çalışmalarına öncelik vermek için SCA'yı gözden geçirirken. Çok şaşırtıcı bir şeyle karşılaştım. Koa.JS'de kritik bir güvenlik açığı mı var?! Her zamanki "#FFS, bütün haftamın yeniden düzenlenmesi gerekiyor." dedikten sonra, "Derin bir nefes al ve bunun neyle ilgili olduğuna bir bak. Geçen sefer olanları hatırlıyorsun..."

Ve ben de yaptım. Her şeyden önce, başlık, "sorunun" 2018'de bulunduğunu açıkça ortaya koyuyor. Şimdi, neden hala korunan bir kitaplıkta bir güvenlik açığım olsun ve sürekli olarak en son sürüme yükseltme yapıyorum? Bu noktada beynimin araştırmacı kısmı devreye girdi.

Bu noktada ne biliyoruz/görüyoruz?

1. İddiaya göre Koa'da 2018'de Kritik önem derecesine sahip bir güvenlik açığı vardı.
2. Sonatype OSS Index ve Dependency Track'e göre sorun beni 2022'de Koa'nın en son sürümünü çalıştırırken etkiliyor

• Koa.JS kitaplığının hangi sürümleri "güvenlik açığından" etkilendi?
• En son Koa.JS'de "güvenlik açığı" varsa

Sorun Analizi

“Güvenlik açığının” ne hakkında/ne hakkında olduğunu görelim. GitHub'dan ilgili sayı #1250'yi hızlıca buraya bağlayayım. Analiz edebilmemiz için aşağıdaki örneği (PoC?) kopyalayıp yapıştıracağım.

const Koa = require('koa');
const app = new Koa();

app.use(async ctx => {
  ctx.redirect("javascript:alert(1);")
});

app.listen(3000);

“Bir web uygulaması veya web hizmeti geliştiricisi olarak, web sitemi ziyaret ederseniz tarayıcınızı istediğim yere yönlendirebilirim.”

Yukarıdaki kodun anlamı budur. Yukarıdaki PoC'de, kötü niyetli bir aktörün herhangi bir şeyi istismar etmesi için sunulan herhangi bir saldırı vektörü yoktur.

Bu güvenlik açığı olmaması için uygun bir "PoC" sağlamak isteseydiniz (evet, az önce söyledim), şöyle görünürdü:

const Koa = require('koa');
const app = new Koa();
// Try: http://localhost:3000/?vector=javascript:alert(1);
app.use(async ctx => {
  ctx.redirect(ctx.request.query.vector);
});

app.listen(3000);

Bir XSS güvenlik açığından bahsetmişken, vectorparametrenin değeri olarak girdiğim her şey HTML bağlamında güvenli olmayan bir şekilde görüntüleniyorsa, uyguladığım uygulama Siteler Arası Komut Dosyası Çalıştırmaya karşı savunmasız olacaktır. (Daha sonra bunun hakkında daha fazla bilgi)

Sonatype'ın bunu nasıl sunduğuna odaklanarak ve biraz daha analiz ederek:

"Siteler Arası Komut Dosyasına Yönelik Açık Yönlendirme"? Her şeyden önce, açık bir yönlendirme yoktu. Yalnızca açarsanız açılır ve iki PoC (orijinal ve benimki) arasındaki fark bunu açıkça gösterir. İlkinde saldırı vektörü yoktu, dolayısıyla açık yönlendirme yoktu. PoC'umda bir saldırı vektörü vardı, filtreleme yoktu, bu nedenle açık bir yönlendirme vardı. Ancak, gördüğünüz gibi, açık bir yönlendirme olup olmadığı bana, geliştiriciye bağlıydı, Koa.JS'ye değil. Daha da iyisi, bir yönlendirme olup olmaması da bana bağlıydı. Yönlendirme URL'si olarak/içinde kullanıcı tarafından sağlanan girişi güvenli olmayan bir şekilde dahil edip etmemek de bana bağlıydı. O zaman hangi Koa.JS güvenlik açığından bahsediyoruz? Teknik olarak bir güvenlik açığı yoktu ve birileri buna hâlâ Kritik önem derecesi atamıştı. Tam olarak profesyonel değil.

Her neyse, uygun PoC tarafından uygulanan söz konusu "güvenlik açığından" "istismar edelim". 3000 numaralı bağlantı noktasını zaten dinlediğim için hizmet bağlantı noktasını 3000'den 4444'e değiştirmem gerektiğini lütfen unutmayın.

LocationYanıt başlığının değerine sahip olduğunu görebiliriz javascript:alert(1). Ardından, tarayıcı şuraya yönlendirir…

Güvendeyim! Açılan uyarı kutusu yoktu. Evet, sorgu parametresinin https://google.comdeğeri olarak girebilir vectorve Google'a yönlendirilebilirdim, bu nedenle uygulamam (PoC) açık yönlendirmeye karşı savunmasızdır, ancak bunun nedeni Koa değil, filtrelenmemiş kullanıcı verilerini ctx.redirect. Endişelendiğim bir şey değil, bunu asla yapmam.

GitHub'daki sorun yorumlarından dikkat edilmesi gereken önemli bir nokta şudur:

Sorun, Koa'nın yönlendirme yanıtının gövdesine bir HTML köprüsü yazdırmasından ve bunun siteler arası komut dosyası çalıştırma saldırısını tetikleyebilmesinden kaynaklanmaktadır.

Ah, bu biraz daha mantıklı! Bakalım hala durum böyle mi?

Hayır, artık durum böyle değil. Yanıt organı yok. Sanırım bu "kırılganlığın" beni etkilemediği sonucuna varabilirim. Bağımlılık İzleme'de gidip bunu yanlış pozitif olarak işaretleyebilirim.

Bağlam Analizi

“Bağlam Analizi”nin tüm güvenlik profesyonelleri tarafından benimsenmesini ve “sorunları” bildirmeden önce yapılmasını öneriyorum. Bu başka bir örnek olsun ve size nasıl yapıldığını göstersin. ( Bağlamın önemini çok daha iyi açıkladığı için yine de CVE-2022–29622: (In)güvenlik açığı Analizini okumanızı tavsiye ederim .)

1. Koa.JS kullanıma hazır, sizi hiçbir yere yönlendirmez. Bu nedenle, Sonatype OSS Index tarafından belirtildiği gibi “Açık Yönlendirme” yoktur ve olmamıştır.
2. GitHub'da sağlanan "PoC"ye dayanarak, bir geliştiricinin XSS'ye yol açabilecek aptalca bir şey yapma fırsatı vardı. Ancak, yukarıdaki # 1'e bakın. Koa.JS kendi başına herhangi bir yönlendirme yapmadı. Aşağıdaki #2'ye bakın.
3. Bildirilen “güvenlik açığının” mevcut olması için bir geliştiricinin uygulamasını güvenli olmayan bir şekilde gerçekleştirmiş olması gerekir. Bu, hemen hemen, Koa.JS'nin daha iyisini yapmış olsa bile, onu savunmasız olarak adlandıramayacağınız anlamına gelir. Bağlamsal olarak uygunsuz. Söz konusu güvenlik açığı, yalnızca güvenli olmayan bir şekilde gerçekleştirilmiş bir web uygulamasında mevcut olabilir .

Size bu gibi durumların en iyi nasıl ele alındığına dair bir örnek vereyim. Swagger Parser'a gönderdiğim bu sayıya ve nasıl iletildiğine bakın. Sorun raporunu inceleyelim:

1. Başlıkta "Güvensiz Çözümleyici Davranışı" yazıyor. Başlıkta LFI'den (Yerel Dosya Dahil Etme) bahsetmiyorum. Bunun nedeni, yerel dosyaları dahil etme potansiyeli olsa da , ŞEYLERİ KARIŞTIRIRSAM, neyle çalıştığımı ve onunla nasıl çalıştığımı bilmek gerçekten bir geliştirici olarak bana bağlı. Varsayılan davranış güvensizdi (belki hala öyledir). Ancak, kütüphane benim katılımım olmadan kendi başına hiçbir şey yapmayacaktır.
2. Daha sonra hangi kütüphane versiyonundan bahsettiğimi açıkça belirtiyorum. Kitaplığın güvenli olmayan varsayılan davranışının bir uygulamayı etkileyeceği koşulları listeleyerek bağlamı daha da netleştiriyorum. Bu, kitaplığın kendisinin savunmasız olmadığını, ancak geliştiricilere yardımcı olmak için geliştirilebilecek güvensiz bir davranışa sahip olduğunu açıkça ortaya koyuyor.
3. Bağlam ayarlandığına göre, çalışan bir PoC, savunmasız bir kod parçacığı (PoC olarak yazdım, Swagger Ayrıştırıcının bir parçası değil!) ve savunmasız bir uygulamanın/hizmetin istismar edilmesinin gerçek sonucunu sağlıyorum. kütüphane güvensiz.
4. Biraz araştırma yaptım ve bir geliştirici olarak kitaplığı sorunu azaltacak şekilde gerçekten yapılandırabileceğimi gördüm. (bir dereceye kadar) Bunu geliştiricilerle paylaştım. Hiç değilse, en azından farkındalığı artırmak için belgeleri güncelleyebilirler.
5. Ek bağlam, analiz ve işlerin nasıl iyileştirilebileceğine dair bir örnek sağladım.

Çözüm

Her şeyden önce, Sonatype, OSS İndeksi ile daha iyi performans göstermeli ve veritabanındaki her güvenlik açığı için sürüm bilgisinin mevcut olduğundan emin olmalıdır. Asgari olan bu. (Bu özel girişi veritabanından tamamen kaldırmak için bonus puanlar.)

Bağımlılık İzlemenin FOMO'dan muzdarip olduğundan şüpheleniyorum, bu nedenle, sürüm numarası mevcut değilse sorunları yalnızca bileşen adı eşleşmesine dayalı olarak bildirmeye isteklidir. Kritik bir güvenlik açığını kaçırma riskini almayacaklarını anlıyorum. Bu davranışla ilgili sorun (yanlış pozitifler), Yazılım Kompozisyon Analizinin benimsenmesini teşvik etmemesidir. Geliştiricileri, statik kod analizinin yanlış pozitifleri gibi korkutacaktır. Zarar verici.

Bağlam! Kanlı bağlam, millet! Öneriyorum:

1. Tüm güvenlik profesyonelleri tarafından benimsenecek ve "sorunları" bildirmeden önce gerçekleştirilecek "Bağlam Analizi"
2. "Güvensiz davranışı" "kırılganlık"tan ayırt etmek
3. Bir yazılım kitaplığı ile bir uygulama/hizmet arasındaki farkı anlamak