Kısa bir süre önce, 2018'de Koa.js'yi etkileyen bir güvenlik açığı hakkında yazmıştım . 2018'de tarih 2022 iken bir sorunla uğraşmak zorunda kaldığım için hayal kırıklığına uğradım ve Koa'nın en son sürümünü kullanıyordum. 4 yıl geçti. Bu uzun bir süre. Elbette sorun artık orada değil!? Ve aynı anda hem vardı hem de değildi. Bu, aynı anda hem hatalı hem de haklı olduğum anlamına gelir. İşte size nasıl yapılacağını anlatmak için önceki gönderiye yönelik bir güncelleme:

• Sonatype ve Dependency Track'i belirli durumlarda sürüm bilgileriyle çalışmamakla haksız yere suçladım
• Bir güvenlik açığı hakkında aynı anda hem haklı hem de haksız olabilirim

OSS İndeksi Versiyon Bilgisine Sahiptir

Önceki yazımı okuduysanız, muhtemelen sorunun beni etkilemediği sonucuna vardığımı hatırlarsınız. İyi haber şu ki ben haklıydım. Kötü haber şu ki, Sonatype'ı OSS Index for Dependency Track'in birlikte çalışması için sağladığı verilerde sürüm numaralarına sahip olmamakla haksız yere suçladım. Bilgiye sahip oldukları ortaya çıktı. Görünmesini beklediğim yerde görünmüyordu. 22/11/2022 tarihinde alınan aşağıdaki ekran görüntüsüne bakın.

Bağımlılık İzleme (DT) büyük olasılıkla yukarıdaki sayfada görüntülenenlerle tam olarak çalışmıyor, ancak DT'nin OSS Dizininden getirdiği verilerin nasıl göründüğünü kontrol etmek umurumda değildi. DT az önce daha fazla bilgi edinebileceğim OSS İndeksine bir bağlantı gösterdi. Tıkladım ve bu sayfaya geldim.
Bugün Sonatype tarafından sürüm numaralarının mevcut olduğu dikkatimi çekti; Başka bir yere bakmalıyım. Nitekim, hesabınıza giriş yapıp Koa'yı ararsanız veya yukarıdaki ekran görüntüsündeki “Koa için ayrıntıları gör” düğmesine tıklarsanız bulabilirsiniz. Aşağıdaki ekran görüntüsüne bakın.

Yani yanılmışım. Sonatype veritabanındaki bilgilere sahiptir. O halde sorun sunum katmanındadır. Gerekirse görüp doğrulayabilmemiz için, güvenlik açığının gerçekten tartışıldığı sayfada etkilenen sürümleri listeleselerdi daha iyi olurdu.

Sonatype OSS Index'i sürüm bilgisine sahip olmamakla haksız yere suçladım. Ayrıca, sürüm bilgileri mevcut değilse, yalnızca bağımlılık adına dayalı olarak rapor vermeye istekli olmakla, Dependency Track'i haksız yere suçladım. (Hala ikincisinin doğru mu yanlış mı olduğunu öğrenmem gerekiyor, kontrol etmedim.)

Henüz pes etmeyin! Tartışılacak daha heyecan verici şeyler, gerçek güvenlik açığı ve (umarız) OSS Dizinindeki güvenlik açığı raporunda yapılacak değişikliklerdir. Güvenlik açığı ile başlayalım.

Siteler Arası Komut Dosyası Çalıştırma

Sonatype, XSS'yi aşağıdaki düşünce sürecine dayanarak Koa'ya bağladı.

Koa, Koa'yı kullanan geliştirici değil, HTML yanıtına URL'yi yazan varlıktır.

Koa'nın hangi URL'lere izin vermek isteyip istemediğiniz hakkında hiçbir fikri olmayacağından, geliştiricinin açık bir yeniden yönlendirmeyi önlemek için sağlanan URL'yi muhtemelen bir izin verilenler listesine göre doğrulamasını beklemek kesinlikle mantıklıdır. Bununla birlikte, bir geliştirici olarak, bir yönlendirme() yöntemine ilettiğim bir URL için XSS temizleme işlemi yapma konusunda endişelenmem gerektiğini düşünmüyorum.

Koa, bu bağlamda XSS'yi önemsiyor gibi görünüyor, çünkü zaten bunu önlemek için orada kodları var, HTML'ye yazdıklarında URL'yi kodlayan HTML varlığı

Bir dereceye kadar katılıyorum. Aşağıdakilere katılmıyorum, örneğin.

Bir yönlendirme () yöntemine ilettiğim bir URL için XSS temizliği yapma konusunda endişelenmem gerektiğini düşünmem

Sizin (geliştiricinin) sağladığı bir yönlendirme yöntemine geçerli, güvenli bir URL iletirseniz, XSS hakkında endişelenmenize gerek yoktur (elbette). Tamamen veya kısmen kullanıcı tarafından sağlanan verileri iletirseniz, ister geliştirici ister güvenlik uzmanı olun, bu her zaman endişelenmeniz gereken bir şeydir. Yine de Koa'nın geliştiriciye yardım etmesini beklemek abartılı değil.

Nereden geldiğimi anlamanıza yardımcı olacağını umduğum harika bir örnek vereyim. Aşağıdaki örnekte, kullanıcı tarafından sağlanan verileri yanıt gövdesindeki tarayıcıya geri iletiyorum. Bunu herhangi bir doğrulama, temizleme veya kodlama olmadan yapıyorum.

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

app.use(async ctx => {
  ctx.body = ctx.query.payload;
});

app.listen(4444);

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=<img%20src=x%20onerror=alert(1)> HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 28
< Date: Wed, 23 Nov 2022 10:59:17 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
<img src=x onerror=alert(1)>%

• Yanıt gövdesinde tarayıcıya neyi ve nasıl ilettiğimi düşünün
• Yanıt için Content-Type başlığının değerini göz önünde bulundurun (ve muhtemelen en iyisi açıkça kontrol etmek!)
• Koa'nın varsayılan olarak, iletilen değere göre Content-Type başlığının değerini otomatik olarak ayarladığını bilin ctx.body. (Örneğin iletmeyi deneyin aaave nasıl değiştiğini görün)

Yukarıdaki ctx.body"XSS" örneğini göz önünde bulundurduğumuzda, ctx.redirect(). Sonatype'tan tekrar alıntı:

Koa, zaten kodları olduğu için bu bağlamda XSS'yi önemsiyor gibi görünüyor.

Bu, Koa'nın bu bağlamda XSS'yi umursamaması durumunda, benzer şekilde, söz konusu olduğunda onu umursamaması (ve umursamaması) ctx.body, kimsenin bunu bir XSS güvenlik açığı olarak işaretlemeyeceği anlamına mı geliyor? Bu oldukça komik. Burada ve burada belgelenen Formidable hakkında daha önceki analizimle bazı benzerlikler fark ettim .

Şimdiye kadar ne söylediysem de, bir XSS orada… ve aynı anda değil. Bu nasıl mümkün olabilir? Basit! Oradadır, ancak aşağıdaki durumlar dışında bundan yararlanamazsınız:

1. Kurban eski bir web tarayıcısı kullanıyor VE
2. ctx.redirect()Geliştirici tarafından Koa's , AND kullanılarak uygulanan açık bir yönlendirme var.
3. Geliştirici, kullanıcı tarafından sağlanan tüm verilere tamamen güvenir ve bunları kelimesi kelimesine aktarır.ctx.redirect()

Sonatype rapor sayfası, bugünkü ekran görüntüsünden de görebileceğiniz gibi, “Siteler Arası Komut Dosyasına Yönelik Açık Yönlendirme” dedi. Bir önceki yazım “açık yönlendirme” kısmını sorgulamıştı:

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.

Sonatype ayrıca, açık yönlendirmeleri engellemekten Koa'nın sorumlu olmadığını da kabul eder. Onların endişesi, benim endişem ve diğer herkesin asıl endişesi XSS idi. Açık yönlendirmeyi dahil etmek sadece kafa karıştırıcıydı. Aynı zamanda, daha sonra göreceğimiz gibi teknik olarak da mantıksız değildi. (Aynı zamanda güvenlik açığı puanlamasını da etkiler.)

Daha önce belirtildiği gibi, Koa'nın davranışından başarıyla yararlanmak için açık bir yeniden yönlendirme gerekir. Fakat:

• Koa, açık yönlendirmeleri engellemekten sorumlu değildir (daha önce belirtildiği gibi)
• ctx.redirect()Koa , geliştiricinin onayı olmadan yürütülmeyecek
• Koa, geliştiricileri yönlendirmeleri kullanmaya zorlamaz

Dolayısıyla, başka bir koruma katmanı daha vardır: kullanım durumları. Bir geliştiricinin bir tarayıcının yönlendirildiği yer üzerinde biraz kontrol istememesi ne kadar olasıdır? Pek olası değil. Bu, büyük olasılıkla, geliştiricilerin kullanıcı tarafından kontrol edilen verileri ctx.redirect()başka bir dize parçasına eklenecekleri anlamına gelir. Bu nedenle, aşağıda gösterilen örneklere benzer bir şeyin olması en olasıdır:

ctx.redirect(`http://website.example.org/search?q=${userInput}`);
ctx.redirect(`/search?topic=${userInput}`);

Güvenlik Açığı Puanlaması

Önceki bölümün sonunda tartışıldığı gibi, açıktan yararlanılabilmesi için üç (3) koşulun karşılanması gerekir.

• Hangi tarayıcı sürümünün kullanılacağı son kullanıcıya bağlıdır.
• Yönlendirme yönteminin kullanımı ve nasıl kullanılacağı geliştiriciye bağlıdır.

Ayrıca üzerinde durulması gereken, yönlendirme yönteminin güvensiz bir şekilde kullanılmasının saldırı vektörü olduğudur. Başarılı bir istismar için bir saldırı vektörü gereklidir. Koa saldırı vektörü sağlamaz; geliştirici yapar.

Bunu NIST tarafından sağlanan "Yazılım Güvenlik Açığı" tanımıyla ilişkilendirelim:

Vurgulamak istediğim kısım “istismar edilebilir”. Koa'yı bir yazılım kütüphanesi olarak alın. Önce gerekli saldırı vektörünü oluşturmadan bundan yararlanabilir misiniz? Hayır. Dolayısıyla, bir yazılım kitaplığı olan Koa'nın bakış açısıyla, hiçbir saldırı vektörü sunulmaz; bu olmadan sömürü imkansızdır. Tanımı katı bir şekilde yorumlasaydık (ki ben öyle yapıyorum), Koa'nın davranışına güvenlik açığı diyemeyiz.
Bir saldırı vektörü olmadan bir CVSS puanı hesaplamaya çalışalım:

Saldırı vektörü yoksa puan da yoktur. Bunun, NIST tarafından sağlanan Yazılım Güvenlik Açığı tanımıyla tutarlı olduğunu söyleyebilirim.
Bir saldırı vektörünün var olduğu hayali bir senaryo deneyelim ve yaratalım.

Hayali saldırı vektörü dışında burada hala birkaç sorun var. Başarılı bir şekilde yararlanma eski bir tarayıcı gerektirdiğinden Saldırı Karmaşıklığı Yüksek olarak ayarlandı. Saldırganın kurbanları eski bir tarayıcı indirip yüklemeye ikna etmesi gerekir.
Bu anlamda, Kullanıcı Etkileşimi temel ölçümleri gerçekten bununla ilgili olmasa da Kullanıcı Etkileşimi gereklidir. Bu senaryoda, XSS'den yararlanmanın kullanıcı etkileşimi gerektirip gerektirmediği, Koa'da değil Web Uygulamasının yönlendirmeleri nasıl kullandığına bağlıdır. Ayrıca, enjekte edilen JavaScript'in, ilk etapta kullanıcı etkileşimi gerektirdiği için kendi başına çalışmayacağını da belirtmekte fayda var: HTML yanıtındaki bağlantıya tıklamak.

Peki bu konuda bir güvenlik açığı puanını zorlamak için ne yapabiliriz? Bir şey seçmeliyiz. Arzu dolu düşünme, en kötüsünü varsayarak, ne istersen. Kesin olan bir şey var ki, aslında yapmamanız gereken bir hesap yapıyorsunuz ve sonuç gerçeklikten o kadar uzak ki, kelimesini bile bulamıyorum.

Bir sonraki büyük şey, Etki Metrikleridir. Etkiyi anlatmak için Web Uygulamasının ne hakkında olduğunu bilmelisiniz. Ancak bir Web Uygulaması için bir güvenlik açığı puanı hesaplamıyoruz… Bağlam göz önüne alındığında, bu XSS'nin Koa üzerinde sıfır etkisi vardır. Koa, gizli bilgileri kendi başına işlemez veya işlemez. Hatanın kullanılabilirlik veya bütünlük üzerinde hiçbir etkisi yoktur. Bu , bir saldırı vektörünü hesaplamaya zorladıktan sonra bile, bize 0,0'lık nihai skor bırakır .

Öyleyse soru şu ki, gerçekleri mi yoksa kurguyu mu bildiriyoruz?

Sonatype , 2019'da CVSSv3.1 ile yayınlanan Yazılım Kitaplıklarında Puanlama Güvenlik Açıkları için resmi kılavuza dikkatimi çekti. Bunu bilmediğimi itiraf ediyorum, bu hem iyi hem de kötü. İyi çünkü bir rant gönderisiyle sonuçlanırdı, kötü çünkü belki daha önce görseydim, bunun doğru yol olmadığını açıklamaya çalışmak için bu kadar çaba harcamadan tüm umudumu kaybederdim. Peki, resmi kılavuz ne diyor?

Bir kitaplıktaki bir güvenlik açığının etkisini puanlarken … Analist, makul en kötü durum uygulama senaryosu için puan vermelidir. Mümkün olduğunda, CVSS bilgileri bu varsayımları detaylandırmalıdır.

Yani cevap, güvenlik açığı puanlamasının kurguya dayalı olduğudur.

Ayrıca, " makul bir en kötü durum uygulama senaryosu" nedir? Koa kullanan birçok projeyi analiz edersek ve çoğu geliştiricinin Koa'nın ctx.redirect()yöntemini kullanarak açık yönlendirmeler uyguladığını bulursak, en kötüsünü varsaymak mantıklı olabilir. GitHub'da JavaScript projelerinde hızlı bir kod araması yaptım . ctx.redirect(16.827 kod sonucu aldım. Arama context.redirect(yaparken 15.751 kod sonucu aldım. Bu, analiz edilecek 32.578 kod sonucu olacaktır. Bunlardan bazıları Koa, bazıları Express kullanacak ve bazıları başka bir şey olabilir. (Elbette, bağlam herhangi bir adla çağrılabilir, yalnızca ctxveya değil context, bu nedenle bakılacak daha fazla kod olabilir.)

Soru şu: Kullanıcı tarafından sağlanan verileri yönlendirmek için beyinsizce geçirmek bu kadar yaygın mı? Arama kriterleriyle eşleşen tüm projeleri kontrol etmek için küçük bir komut dosyası yazarak yarı otomatik bir analiz yaklaşımı benimsedim. Ne yazık ki, GitHub diğer istekleri reddettiği için ilk 1000 isabeti geçemedim:

{
    "message":"Only the first 1000 search results are available",
    "documentation_url":"https://docs.github.com/v3/search/"
}

Gördüklerime dayanarak ve bir sonraki bölümde ("Eski Web Tarayıcı") tartışılanları göz önünde bulundurarak, en kötü durum uygulamasının makul olacağına inanmıyorum. Bu özel durumda değil.

Resmi rehberlik ayrıca şunları söylüyor:

Etkilenen kitaplığı kullanarak belirli bir uygulamadaki bir güvenlik açığını puanlarken, söz konusu uygulama için puanın yeniden hesaplanması gerekir.

Bu makul ve durumun bilimkurgu yönünü bir nebze olsun hafifletiyor. Güvenlik açığı puanı 9.8 olan bu Koa sorunu, bizim durumumuzda bu şekilde 0,0 olarak sonuçlandı.

İyi olan şey, Sonatype'ın 9.8 güvenlik açığı puanının mantıksız olduğu konusunda hemfikir olması ve bunu düşürmeye istekli olmaları. Bunu takdir ediyorum ve muhtemelen başkaları da takdir edecek.

Ayrıca Sonatype, sorunu sistemlerine eklediklerinde, müşterilerinin bu potansiyel olarak beklenmedik durumu bilmelerinin en iyisi olacağına inandıklarını söyledi. "Gördüklerimizi görmezden gelmekten ve potansiyel olarak olumsuz bir sonuç doğurmaktansa uyarmak daha iyidir" dediler. Ve elbette haklıydılar.

Güvenlik sorunlarının iletilmesi gerekip gerekmediğini asla sorgulamadım. Evet, güvenlik sorunları görünür kılınmalıdır. Beni endişelendiren, bu konuların nasıl iletildiği:

• Bir şeyi güvenlik açığı olarak adlandırmak uygun mu yoksa güvenlik zayıflığı veya güvensiz varsayılan davranış vb. olarak adlandırmak daha mı uygun?
• Atanan güvenlik açığı puanı makul mü?
• Yeterli ayrıntı ve bağlam sağlandı mı?

Şimdi biraz eski web tarayıcılarından bahsedelim.

Eski Web Tarayıcısı

Sonatype'ın iyi insanları olmasaydı, muhtemelen bir daha asla eski web tarayıcılarını düşünmezdim.

Gelecekte de eski tarayıcıları düşünmemeye devam edeceğim. Öncelikle akılda tutulması gereken çok fazla şey var; Eski web tarayıcıları hakkında endişelenemem. İkincisi, eski bir web tarayıcısı (espri anlayışınız yoksa bağlantıya tıklamayın!) kaç yaşında ? "Eski" gerçekten ne anlama geliyor? Herhangi biri sadece ~ 1 yaşında bir tarayıcı kullanıyorsa, büyük ihtimalle zaten XSS'den çok daha büyük sorunları vardır .

Yine de biraz araştırma yaptım ve şunu buldum:

• 2016'dan Google Chrome 48.0.2564.109 (64-bit) (!) yanıt gövdesini bile göstermedi. 2018'de Koa konusu bulununca 2016'ya kadar gitmenin yeterli olacağını düşündüm ama öyle olmadığı ortaya çıktı.
• 2011'den Firefox 4.0, yanıt gövdesini görüntüledi, ancak JavaScript yükünün yürütülmesi için kullanıcıların bağlantıya tıklaması gerekiyordu. (Tabii ki bu bir bağlantı!)
• Koa XSS sorununun bildirilmesinden 1 yıl önce, 2017 tarihli Firefox 52.0, JavaScript yüküyle yanıt gövdesini zaten göstermiyordu. Firefox, "ağ protokolü ihlali" nedeniyle "Bozuk İçerik Hatası" diyen bir hata attı.

Koa 0.0.1 2013'te piyasaya sürüldü, bu nedenle sorunun istismar edilebileceği birkaç yıl vardı. Bu itibarla, 2018'de Koa 2.5.0'a kadar (hala 9.8 puanla değil) bu sorunu işaretlemek muhtemelen kabul edilebilir olacaktır.

Araştırma yaparken Wikipedia'da ilginç bir şey buldum . Alıntı yapayım:

Firefox 15, 28 Ağustos 2012'de piyasaya sürüldü … Firefox 15, Firefox'u kullanıcıyı bilgilendirmeden en son sürüme güncelleyen otomatik bir güncelleme olan sessiz güncellemeler getirdi [65] , Google Chrome ve Internet Explorer 8 ve sonraki sürümlerin sahip olduğu bir özellik zaten uygulandı

Bu nedenle, Koa'nın ilk sürümü piyasaya sürülmeden önce tüm büyük web tarayıcılarının otomatik güncelleme özelliği vardı, bu da kullanıcıların büyük çoğunluğunun güncel bir web tarayıcısı kullandığı anlamına geliyor. “Büyük patlama” sırasındaki durumu görelim: 2013.

• Firefox 15 : "Bozuk İçerik Hatası" şeklinde bir hata döndürdü, yani yanıt gövdesi kullanıcıya gösterilmedi.
• Chrome 24.0.1312 (WebKit 537.17) : Herhangi bir yanıt gövdesi göstermedi. Geliştirici araçlarının ağ sekmesine baktığımda neredeyse hiçbir şey görünmüyordu, bu yüzden tarayıcının isteği ilk başta gerçekleştirip gerçekleştirmediğini görmek için Wireshark'ı çalıştırmam gerekti. Wireshark'ta, Chrome'un PoC hizmetime ulaştığı ve yanıtı JavaScript yüküyle aldığı görüldü. Yanıt gövdesini oluşturmadı. Daha da iyisi, hiçbir şey olmadı.
• Internet Explorer 11 (11.0.9600.19180) : Wireshark kullanarak doğruladığım PoC hizmetimden yanıt getirdi. Yanıt gövdesini kullanıcıya göstermedi. "Bu sayfa görüntülenemiyor" yazan klasik yerleşik hata sayfasıyla geri döndü.

Yukarıdaki araştırmayı yaptıktan sonra, bir saniye için Sonatype'tan bir alıntıya geri dönelim:

Koa, bu bağlamda XSS'yi önemsiyor gibi görünüyor, çünkü zaten bunu önlemek için orada kodları var, HTML'ye yazdıklarında URL'yi kodlayan HTML varlığı

Bu ifade doğru olsa da, Koa'nın ilk sürümü piyasaya sürüldüğünde büyük tarayıcılardan hiçbirinin istismara izin vermemesi, alıntının ilginç bir şeye, cümlenin önermek istediğinden başka bir şeye işaret ediyor. Koa geliştiricilerinin tam olarak nasıl düşündüklerini tam olarak bilemeyeceğim için spekülasyon yazmak üzere olduğumu lütfen unutmayın. Geliştiricilerin söz konusu davranışı güncel bir web tarayıcısı kullanarak test ettiğini kolayca tahmin edebiliyorum. hrefHTML kodlamasının uygun olduğunu bulmuş olabilirler, çünkü enjekte edilen JavaScript kodunun özelliğinden çalıştırılması zaten imkansızdı.aetiket. Bu ciddi bir soruyu gündeme getiriyor. Son beş yılı daha fazla yazılım geliştirme tarafında geçirmiş biri olarak, benim için de geçerli: Bir geliştirici olarak, arka uç için yeni bir web teknolojisi oluşturmak üzereysem, eski web tarayıcılarını önemsemeli miyim? Ve eğer yapmam gerekirse, eski web tarayıcılarını ne kadar geriye götürmem gerektiğine dair güvenlik topluluğunun resmi tavsiyesi nedir? Son kullanıcılar için en iyi güvenlik uygulamasının tarayıcılarını güncel tutmak olduğunu ve otomatik güncelleme özelliğinin de bu konuda yardımcı olduğunu düşünmemeli miyiz? Ayrıca, geliştiricilerin aklında tutmasını ve eski tarayıcılarla test etmesini beklersek, güvenlik uzmanlarının da aynı şeyi yapmasını ve yalnızca "eski tarayıcılara" atıfta bulunmak yerine belirli bir soruna katkıda bulunan tüm web tarayıcılarını ve sürümlerini adlandırmasını bekleyemez miyiz? ”? Sadece adil olurdu.

Kesin olan bir şey var ki, yıllardır endişelenecek bir şey yok…

Modern Tarayıcı

Analizimde web tarayıcımı kullanarak yanıt gövdesini kontrol ettim ve boş buldum. Tel üzerinden gönderilen yanıtın bir gövdesi olup olmadığını kontrol etmedim. Yanıt gövdesini tamamen yok sayan yalnızca Google Chrome olduğu ortaya çıktı; bu nedenle göstermedi. Bu benim için yeterince iyiydi. Makul olarak, eklemeliyim.

O zamandan beri, test web hizmetimin yanıtına Koa'nın en son sürümünü kullanarak baktım. Aşağıda, enjekte edilen JavaScript kodunu içeren bir HTML yanıt gövdesi olduğunu görebiliriz:

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=javascript:alert(1); HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: javascript:alert(1);
< Content-Type: text/html; charset=utf-8
< Content-Length: 71
< Date: Tue, 22 Nov 2022 17:55:12 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="javascript:alert(1);">javascript:alert(1);</a>.

*   Trying 127.0.0.1:4444...
* Connected to 127.0.0.1 (127.0.0.1) port 4444 (#0)
> GET /?payload=%22><%2f HTTP/1.1
> Host: 127.0.0.1:4444
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: %22%3E%3C/
< Content-Type: text/html; charset=utf-8
< Content-Length: 61
< Date: Tue, 22 Nov 2022 22:18:49 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
< 
* Connection #0 to host 127.0.0.1 left intact
Redirecting to <a href="&quot;&gt;&lt;/">&quot;&gt;&lt;/</a>.

Yaklaşan Değişiklikler

Sonatype'ın bu sorunla ilgili olarak uygulamayı planladığı güncellemelerin listesi aşağıdadır:

• Yanlış anlamaları ortadan kaldırmak için Özet/Başlık satırının güncellenmesi (zaten oldu)
• Güvenlik açığı puanını 4,7'ye düşürme (zaten oldu)
• Güvenlik açığından yalnızca bir kullanıcı eski bir tarayıcı çalıştırıyorsa yararlanılabileceğinden bahsedin

Görmek İstediğim Ek Değişiklikler

Önceki bölümde bahsedilen değişikliklerin yanı sıra, birkaç şey daha da geliştirilebilir. Bunlar:

• Özellikle 2018'den sonra yayınlanan Koa sürümleri için güvenlik açığı puanını daha da azaltmak.
• En azından başlıca web tarayıcılarının sürüm numarası ve "eski tarayıcılara" atıfta bulunurken raporda yer alan yayınlanma tarihleri ​​dahil. Bu, "etkilenen kitaplığı kullanarak belirli bir uygulamadaki bir güvenlik açığını puanlarken" herkese önemli ölçüde yardımcı olacaktır. Örneğin, bir kullanıcının 2011'den kalma bir tarayıcı kullanması gerektiğini görseydim, sorunu bir saniye içinde SCA'da "etkilenmedi" olarak işaretlerdim. Çok zaman kazanıldı.
• Etkilenen Koa sürümleri güvenlik açığı sayfasında listelenecektir .

Bu arada Sonatype, ticari tekliflerinde, örneğin bir uygulamanın bildirilen güvenlik açıklarından etkilenip etkilenmediğini görmek için kod düzeyinde gerçek kontroller gerçekleştiren bazı harika kontroller olduğunu da belirtti. Kulağa hoş geliyor ve kütüphaneler için güvenlik açığı puanlarının nasıl hesaplandığı bilim kurgu doğası göz önüne alındığında, bu tür kontroller, özellikle işler böyle devam ederse, mühendislik ekiplerinin üzerindeki yükü azaltmak için olmazsa olmazdır.

Çözüm

Sahip olduğum tüm güncellemeler bu kadar. Sonatype'a ulaştığıma sevindim çünkü çok profesyonel ve arkadaş canlısılar. Bu konuda onlarla çalışmak bir zevkti.

Koa'daki XSS ile ilgili olarak: bu, birkaç yıldır hiçbirimizin endişelenmemesi gereken bir şey.