Belum lama ini, saya menulis tentang kerentanan yang memengaruhi Koa.js pada tahun 2018. Saya merasa frustrasi karena harus menangani masalah dari tahun 2018 padahal tanggalnya adalah tahun 2022, dan saya menggunakan Koa versi terbaru. 4 tahun telah berlalu. Itu waktu yang lama. Pasti masalahnya sudah tidak ada lagi!? Dan itu dan tidak pada waktu yang sama. Itu berarti saya salah dan benar pada saat bersamaan. Jadi, berikut adalah pembaruan untuk posting sebelumnya untuk memberi tahu Anda caranya:

• Saya salah menuduh Sonatype dan Dependency Track tidak beroperasi dengan informasi versi dalam kasus tertentu
• Saya bisa benar dan salah pada saat yang sama tentang kerentanan

Indeks OSS memiliki Informasi Versi

Jika Anda telah membaca posting saya sebelumnya, Anda mungkin ingat bahwa saya menyimpulkan bahwa masalah tersebut tidak memengaruhi saya. Kabar baiknya adalah bahwa saya benar. Berita buruknya adalah saya salah menuduh Sonatype tidak memiliki nomor versi dalam data yang disediakan oleh OSS Index untuk Dependency Track untuk digunakan. Ternyata mereka memang punya informasinya. Itu tidak terlihat di tempat yang saya harapkan seharusnya terlihat. Lihat tangkapan layar di bawah yang diambil pada 22/11/2022.

Sepertinya Dependency Track (DT) tidak bekerja dengan tepat seperti yang ditampilkan pada halaman di atas, tetapi saya tidak peduli untuk memeriksa seperti apa data yang diambil DT dari OSS Index. DT baru saja menunjukkan tautan ke Indeks OSS, tempat saya dapat mempelajari lebih lanjut. Saya mengklik dan mendarat di halaman ini.
Itu menjadi perhatian saya oleh Sonatype hari ini bahwa nomor versi tersedia; Saya harus mencari di tempat lain. Memang, jika Anda masuk ke akun Anda dan mencari Koa atau mengklik tombol "Lihat detail untuk koa" di tangkapan layar di atas, Anda dapat menemukannya. Lihat tangkapan layar di bawah ini.

Jadi saya salah. Sonatype memang memiliki informasi dalam database. Masalahnya adalah dengan lapisan presentasi, kalau begitu. Akan lebih baik jika mereka memiliki versi yang terpengaruh terdaftar di halaman tempat kerentanan dibahas sehingga kami dapat melihat dan memverifikasi jika diperlukan.

Saya salah menuduh Sonatype OSS Index tidak memiliki informasi versi. Saya juga salah menuduh Dependency Track bersedia melaporkan hanya berdasarkan nama dependensi jika informasi versi tidak tersedia. (Saya masih perlu mencari tahu apakah yang terakhir itu benar atau salah, saya tidak memeriksanya.)

Jangan menyerah dulu! Hal yang lebih menarik untuk didiskusikan adalah kerentanan aktual dan (semoga) perubahan yang akan datang pada laporan kerentanan di Indeks OSS. Mari kita mulai dengan kerentanannya.

Pembuatan Skrip Lintas Situs

Sonatype mengaitkan XSS dengan Koa berdasarkan proses pemikiran di bawah ini.

Koa adalah entitas yang menulis URL ke respons HTML, bukan pengembang yang menggunakan Koa

Sangat masuk akal untuk mengharapkan pengembang memvalidasi URL yang disediakan, kemungkinan terhadap daftar yang diizinkan, untuk mencegah pengalihan terbuka dan bukan Koa karena Koa tidak tahu URL mana yang ingin Anda izinkan atau tidak. Namun, sebagai pengembang, saya tidak berpikir saya harus khawatir tentang melakukan sanitasi XSS untuk URL yang saya berikan ke metode redirect().

Koa tampaknya peduli dengan XSS dalam konteks ini karena mereka sudah memiliki kode di sana untuk mencegahnya, entitas HTML yang menyandikan URL saat mereka menulisnya ke HTML

Saya setuju sampai batas tertentu. Saya tidak setuju dengan adalah sebagai berikut, misalnya.

Saya tidak berpikir saya harus khawatir melakukan sanitasi XSS untuk URL yang saya berikan ke metode redirect()

Jika Anda mengirimkan URL yang valid dan aman ke metode pengalihan yang Anda (pengembang) berikan, Anda tidak perlu khawatir tentang XSS (jelas). Jika Anda memberikan data yang disediakan pengguna sepenuhnya atau sebagian, itu adalah sesuatu yang harus selalu Anda khawatirkan, apakah Anda seorang pengembang atau profesional keamanan. Tetap saja, tidak terlalu mengada-ada untuk mengharapkan Koa membantu pengembang.

Biarkan saya memberi Anda contoh yang sangat baik yang mudah-mudahan membantu untuk memahami dari mana saya berasal. Pada contoh di bawah ini, saya meneruskan data yang disediakan pengguna kembali ke browser di badan tanggapan. Saya melakukan ini tanpa validasi, sanitasi, atau pengodean apa pun.

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)>%

• Pikirkan tentang apa dan bagaimana saya meneruskan ke browser di badan respons
• Pertimbangkan (dan mungkin yang terbaik untuk mengontrol secara eksplisit!) nilai header Content-Type untuk respons
• Ketahuilah bahwa Koa, secara default, secara otomatis menyesuaikan nilai header Content-Type berdasarkan nilai yang diteruskan ke ctx.body. (Coba lewati, misalnya aaa, dan lihat bagaimana perubahannya)

Mempertimbangkan ctx.bodycontoh "XSS" di atas, sepertinya kami menyalahkan Koa karena menerapkan tindakan khusus untuk mencegah bencana saat menggunakan ctx.redirect(). Mengutip Sonatype lagi:

Koa tampaknya peduli dengan XSS dalam konteks ini karena mereka sudah memiliki kode di sana.

Apakah ini berarti jika Koa tidak peduli dengan XSS dalam konteks ini, sama seperti bagaimana mereka tidak (dan seharusnya) tidak peduli tentang hal itu ctx.body, tidak ada yang akan menandainya sebagai kerentanan XSS? Itu cukup lucu. Saya melihat beberapa kemiripan dengan analisis saya sebelumnya tentang Formidable yang didokumentasikan di sini dan di sini .

Setelah mengatakan apa pun yang saya katakan sejauh ini, XSS kebetulan ada di sana… dan tidak pada waktu yang bersamaan. Bagaimana mungkin? Sederhana! Itu ada di sana, tetapi Anda tidak dapat mengeksploitasinya kecuali:

1. Korban menggunakan browser web lama, DAN
2. Ada pengalihan terbuka yang diterapkan oleh pengembang menggunakan Koa ctx.redirect(), AND
3. Pengembang memercayai semua data yang disediakan pengguna sepenuhnya dan meneruskannya secara verbatimctx.redirect()

Laman laporan Sonatype mengatakan seperti yang Anda lihat dari tangkapan layar hari ini, "Buka pengalihan yang mengarah ke Pembuatan Skrip Lintas Situs". Posting saya sebelumnya mempertanyakan bagian "pengalihan terbuka":

Pertama-tama, tidak ada pengalihan terbuka. Ini hanya terbuka jika Anda membukanya dan perbedaan antara kedua PoC (yang asli dan milik saya) dengan jelas menunjukkan hal ini.

Sonatype juga setuju bahwa Koa tidak bertanggung jawab untuk mencegah pengalihan terbuka. Perhatian mereka, perhatian saya, dan perhatian utama semua orang adalah XSS. Melibatkan pengalihan terbuka hanya membingungkan. Pada saat yang sama, secara teknis tidak masuk akal, seperti yang akan kita lihat nanti. (Ini juga akan berdampak pada penilaian kerentanan.)

Seperti disebutkan sebelumnya, berhasil mengeksploitasi perilaku Koa memerlukan pengalihan terbuka. Tetapi:

• Koa tidak bertanggung jawab untuk mencegah pengalihan terbuka (seperti yang disimpulkan sebelumnya)
• Koa tidak akan dieksekusi ctx.redirect()tanpa persetujuan pengembang
• Koa tidak memaksa pengembang untuk menggunakan pengalihan

Jadi, ada lapisan perlindungan lain: kasus penggunaan. Seberapa besar kemungkinan pengembang tidak menginginkan kendali atas ke mana browser dialihkan? Sangat tidak mungkin. Artinya, kemungkinan besar, pengembang akan meneruskan data yang dikontrol pengguna untuk ctx.redirect()ditambahkan ke bagian string lainnya. Jadi, sesuatu yang mirip dengan contoh di bawah ini adalah yang paling mungkin terjadi:

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

Penilaian Kerentanan

Harus ada tiga (3) syarat yang dipenuhi agar bug dapat dieksploitasi, seperti yang dibahas di akhir bagian sebelumnya.

• Versi browser apa yang digunakan terserah pengguna akhir
• Penggunaan metode redirect dan cara penggunaannya terserah developer

Yang juga perlu ditekankan adalah bahwa penggunaan metode pengalihan dengan cara yang tidak aman adalah vektor serangan. Vektor serangan diperlukan untuk keberhasilan eksploitasi. Koa tidak menyediakan vektor serangan; pengembang tidak.

Mari kita hubungkan ini dengan definisi "Kerentanan Perangkat Lunak" yang disediakan oleh NIST:

Bagian yang ingin saya soroti adalah "dapat dieksploitasi". Ambil Koa sebagai perpustakaan perangkat lunak. Bisakah Anda mengeksploitasinya tanpa membuat vektor serangan yang diperlukan terlebih dahulu? Tidak. Jadi, dari perspektif Koa, sebuah pustaka perangkat lunak, tidak ada vektor serangan yang disajikan; tanpa itu, eksploitasi tidak mungkin dilakukan. Jika kami menafsirkan definisi secara ketat (yang saya lakukan), kami tidak dapat menyebut perilaku Koa sebagai kerentanan.
Mari kita coba menghitung skor CVSS tanpa vektor serangan:

Tidak ada skor jika tidak ada vektor serangan. Saya akan mengatakan ini konsisten dengan definisi Kerentanan Perangkat Lunak yang disediakan oleh NIST.
Mari bereksperimen dan buat skenario imajiner di mana ada vektor serangan.

Masih ada beberapa masalah di sini, selain vektor serangan imajiner. Kompleksitas Serangan disetel ke Tinggi karena eksploitasi yang berhasil membutuhkan browser lama. Penyerang harus meyakinkan korban untuk mengunduh dan memasang peramban lama.
Dalam hal itu, Interaksi Pengguna diperlukan, meskipun metrik dasar Interaksi Pengguna tidak benar-benar tentang itu. Dalam skenario ini, apakah mengeksploitasi XSS memerlukan interaksi pengguna tergantung pada bagaimana Aplikasi Web menggunakan pengalihan dan bukan pada Koa. Perlu juga disebutkan bahwa JavaScript yang disuntikkan tidak akan dijalankan sendiri karena memerlukan interaksi pengguna sejak awal: mengeklik tautan di respons HTML.

Jadi apa yang bisa kita lakukan untuk memaksakan skor kerentanan ini? Kita harus memilih sesuatu. Berangan-angan, dengan asumsi yang terburuk, apa pun yang Anda suka. Satu hal yang pasti, Anda melakukan perhitungan yang seharusnya tidak Anda lakukan, dan hasilnya sangat jauh dari kenyataan sehingga saya bahkan tidak dapat menemukan kata-kata untuk itu.

Hal besar berikutnya adalah Metrik Dampak. Anda harus tahu apa yang akan diberitahukan oleh Aplikasi Web tentang dampaknya. Tapi kami tidak menghitung skor kerentanan untuk Aplikasi Web… Mengingat konteksnya, XSS ini tidak berdampak apa-apa pada Koa. Koa tidak menangani atau memproses informasi rahasia sendiri. Bug tidak berdampak pada ketersediaan atau integritas. Itu memberi kita skor akhir 0,0, bahkan setelah memaksakan vektor serangan ke dalam perhitungan.

Jadi pertanyaannya, apakah kita melaporkan fakta atau fiksi?

Sonatype menarik perhatian saya panduan resmi untuk Menskor Kerentanan di Perpustakaan Perangkat Lunak , yang dirilis pada 2019 dengan CVSSv3.1. Saya akui saya tidak tahu tentang itu, yang baik dan buruk. Bagus karena itu akan menghasilkan postingan kata-kata kasar, buruk karena mungkin jika saya melihatnya lebih awal, saya akan kehilangan semua harapan saya sebelum saya berusaha keras untuk mencoba menjelaskan bahwa itu bukan cara yang tepat untuk melakukannya. Jadi, apa yang dikatakan pedoman resmi?

Saat menilai dampak kerentanan di perpustakaan ... Analis harus menilai skenario implementasi kasus terburuk yang masuk akal. Jika memungkinkan, informasi CVSS harus merinci asumsi ini.

Jadi jawabannya adalah penilaian kerentanan didasarkan pada fiksi.

Juga, apa itu " skenario implementasi kasus terburuk yang masuk akal "? Jika kami menganalisis banyak proyek yang menggunakan Koa dan menemukan bahwa sebagian besar pengembang menerapkan pengalihan terbuka menggunakan ctx.redirect()metode Koa, mungkin masuk akal untuk menganggap yang terburuk. Saya melakukan pencarian kode cepat di proyek JavaScript ctx.redirect(di GitHub. Saya mendapat 16.827 hasil kode. Mencari context.redirect(saya menerima 15.751 hasil kode. Itu akan menjadi 32.578 hasil kode untuk dianalisis. Beberapa di antaranya akan menggunakan Koa, beberapa Express, dan beberapa mungkin menggunakan yang lain. (Tentu saja, konteksnya dapat dipanggil dengan nama apa pun, tidak hanya ctxatau context, jadi mungkin ada lebih banyak kode untuk dilihat.)

Pertanyaannya adalah: apakah mengirimkan data yang disediakan pengguna tanpa otak untuk mengarahkan ulang begitu umum? Saya mengambil pendekatan analisis semi-otomatis dengan menulis skrip kecil untuk memeriksa semua proyek yang cocok dengan kriteria pencarian. Sayangnya, saya tidak dapat melewati 1.000 hit pertama karena GitHub menolak permintaan lebih lanjut:

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

Berdasarkan apa yang telah saya lihat dan mempertimbangkan apa yang dibahas di bagian selanjutnya (“Browser Web Lama”), saya tidak yakin dengan asumsi penerapan kasus terburuk akan masuk akal. Tidak dalam kasus khusus ini.

Pedoman resmi juga mengatakan bahwa:

Saat menskor kerentanan dalam implementasi tertentu menggunakan library yang terpengaruh, skor harus dihitung ulang untuk implementasi spesifik tersebut.

Ini masuk akal dan mengurangi aspek fiksi ilmiah dari situasi tersebut sampai batas tertentu. Beginilah masalah Koa ini, dengan skor kerentanan 9,8, berakhir menjadi 0,0 dalam kasus kami.

Hal baiknya adalah Sonatype setuju bahwa skor kerentanan 9,8 tidak masuk akal, dan mereka bersedia menguranginya. Saya menghargainya, dan mungkin banyak orang lain juga akan menyukainya.

Selain itu, Sonatype memberi tahu saya bahwa ketika mereka menambahkan masalah ke sistem mereka, mereka yakin akan lebih baik jika pelanggan mereka mengetahui tentang situasi yang berpotensi tidak terduga ini. Mereka berkata, "lebih baik waspada daripada mengabaikan apa yang kita lihat dan berpotensi memiliki hasil negatif". Dan, tentu saja, mereka benar.

Saya tidak pernah mempertanyakan apakah masalah keamanan harus dikomunikasikan atau tidak. Ya, masalah keamanan harus dibuat terlihat. Yang saya khawatirkan adalah bagaimana masalah ini dikomunikasikan:

• Apakah tepat untuk menyebut sesuatu sebagai kerentanan atau lebih tepat menyebutnya sebagai kelemahan keamanan atau perilaku default yang tidak aman, dan seterusnya?
• Apakah skor kerentanan yang ditetapkan masuk akal?
• Apakah rincian dan konteks yang memadai disediakan?

Sekarang mari kita bicara sedikit tentang browser web lama.

Peramban Web Lama

Tanpa orang-orang Sonatype yang baik, saya tidak akan memikirkan browser web lama, mungkin tidak akan pernah lagi.

Saya akan terus tidak mempertimbangkan browser lama di masa mendatang juga. Pertama-tama, terlalu banyak hal yang perlu diingat; Saya tidak perlu khawatir tentang browser web lama. Kedua, berapa lama ( jangan klik tautan jika Anda tidak memiliki selera humor! ) browser web lama? Apa sebenarnya arti "tua" itu? Jika ada yang hanya menggunakan browser berusia ~1 tahun, kemungkinan besar mereka sudah memiliki masalah yang jauh lebih besar daripada XSS.

Tetap saja, saya melakukan penggalian dan menemukan bahwa:

• Google Chrome 48.0.2564.109 (64-bit) dari 2016 (!) bahkan tidak menampilkan badan respons. Karena masalah Koa ditemukan pada tahun 2018, saya pikir mundur sejauh 2016 sudah cukup, tetapi ternyata tidak.
• Firefox 4.0 dari 2011 memang menampilkan badan respons, tetapi mengharuskan pengguna untuk mengklik tautan agar muatan JavaScript dapat dieksekusi. (Tentu saja, itu tautan!)
• Firefox 52.0 dari 2017, 1 tahun sebelum masalah Koa XSS dilaporkan, sudah tidak menampilkan badan tanggapan dengan muatan JavaScript. Firefox baru saja melontarkan kesalahan yang mengatakan "Kesalahan Konten Rusak" karena "pelanggaran protokol jaringan".

Koa 0.0.1 dirilis pada tahun 2013, jadi ada beberapa tahun ketika masalah tersebut dapat dieksploitasi. Sampai saat ini, mungkin dapat diterima untuk menandai masalah ini (masih belum dengan skor 9,8) hingga Koa 2.5.0 pada tahun 2018. Namun, setelah itu, tidak ada yang membenarkan apa pun di atas 1,0.

Saat saya menggali, saya menemukan sesuatu yang menarik di Wikipedia . Izinkan saya mengutip:

Firefox 15 dirilis pada 28 Agustus 2012 … Firefox 15 memperkenalkan pembaruan senyap, pembaruan otomatis yang akan memperbarui Firefox ke versi terbaru tanpa memberi tahu pengguna, [65] fitur yang dimiliki browser web Google Chrome dan Internet Explorer 8 ke atas telah dilaksanakan

Jadi semua browser web utama memiliki fitur pembaruan otomatis sebelum versi pertama Koa dirilis, yang berarti kemungkinan besar sebagian besar pengguna menggunakan browser web terbaru. Mari kita lihat keadaan pada saat “big bang”: 2013.

• Firefox 15 : Mengembalikan kesalahan yang mengatakan "Kesalahan Konten Rusak", yang berarti badan respons tidak ditampilkan kepada pengguna.
• Chrome 24.0.1312 (WebKit 537.17) : Tidak menampilkan badan tanggapan apa pun. Saat melihat tab jaringan alat pengembang, hampir tidak ada yang terlihat, jadi saya harus menjalankan Wireshark untuk melihat apakah browser melakukan permintaan terlebih dahulu. Di Wireshark, terlihat bahwa Chrome menjangkau layanan PoC saya dan menerima respons dengan muatan JavaScript. Itu tidak membuat badan tanggapan. Bahkan lebih baik, tidak ada yang terjadi.
• Internet Explorer 11 (11.0.9600.19180) : Itu mengambil respons dari layanan PoC saya, yang saya verifikasi menggunakan Wireshark. Itu tidak menunjukkan badan respons kepada pengguna. Itu kembali dengan halaman kesalahan bawaan klasik yang mengatakan, "Halaman ini tidak dapat ditampilkan".

Setelah melakukan penelitian di atas, mari kembali ke kutipan dari Sonatype sejenak:

Koa tampaknya peduli dengan XSS dalam konteks ini karena mereka sudah memiliki kode di sana untuk mencegahnya, entitas HTML yang menyandikan URL saat mereka menulisnya ke HTML

Meskipun pernyataan ini benar, fakta bahwa tidak ada browser utama yang mengizinkan eksploitasi pada saat versi pertama Koa dirilis, kutipan tersebut menunjukkan sesuatu yang menarik, sesuatu selain dari apa yang ingin disarankan oleh kalimat tersebut. Harap dicatat bahwa saya akan menulis spekulasi karena saya tidak tahu persis bagaimana pemikiran pengembang Koa. Saya dapat dengan mudah membayangkan pengembang melakukan pengujian perilaku tersebut menggunakan browser web terbaru. Mereka mungkin telah menemukan bahwa pengkodean HTML cocok karena sudah tidak mungkin untuk mengeksekusi kode JavaScript yang disuntikkan dari hrefpropertiamenandai. Ini menimbulkan pertanyaan serius. Setelah menghabiskan lima tahun terakhir lebih banyak di sisi pengembangan perangkat lunak, itu juga berlaku untuk saya: Sebagai pengembang, jika saya akan membuat teknologi web baru untuk sisi backend, haruskah saya peduli dengan browser web lama? Dan jika saya harus, apa rekomendasi resmi dari komunitas keamanan mengenai seberapa jauh saya harus mempertimbangkan browser web lama? Haruskah kita tidak mempertimbangkan bahwa praktik terbaik keamanan untuk pengguna akhir adalah menjaga browser mereka tetap mutakhir, dan fitur pembaruan otomatis juga ada untuk membantu? Juga, jika kami mengharapkan pengembang untuk mengingat dan menguji dengan browser lama, tidak dapatkah kami mengharapkan profesional keamanan untuk melakukan hal yang sama dan memberi nama semua browser web dan versinya yang berkontribusi pada masalah tertentu alih-alih hanya merujuk ke "browser lama ”? Itu hanya adil.

Satu hal yang pasti, tidak ada yang perlu dikhawatirkan sejak bertahun-tahun sekarang…

Peramban Modern

Dalam analisis saya, menggunakan browser web saya, saya memeriksa isi respons dan ternyata kosong. Saya tidak memeriksa apakah respons yang dikirim melalui kabel memiliki badan. Ternyata hanya Google Chrome yang sepenuhnya mengabaikan badan respons; oleh karena itu, itu tidak ditampilkan. Itu sudah cukup bagus bagi saya. Wajar, saya harus menambahkan.

Sejak itu, saya telah melihat respons layanan web pengujian saya menggunakan Koa versi terbaru. Kita dapat melihat di bawah bahwa ada badan respons HTML dengan kode JavaScript yang disuntikkan di sana:

*   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>.

Perubahan Mendatang

Di bawah ini adalah daftar pembaruan yang direncanakan Sonatype untuk diterapkan terkait masalah ini:

• Pembaruan garis Ringkasan/Judul untuk menghilangkan kesalahpahaman (sudah terjadi)
• Mengurangi skor kerentanan menjadi 4,7 (sudah terjadi)
• Sebutkan bahwa kerentanan hanya dapat dieksploitasi jika pengguna menjalankan browser lama

Perubahan Tambahan yang Ingin Saya Lihat

Selain perubahan yang disebutkan di bagian sebelumnya, beberapa hal dapat ditingkatkan lebih lanjut. Ini adalah:

• Mengurangi skor kerentanan lebih lanjut, terutama untuk versi Koa yang dirilis setelah 2018.
• Menyertakan nomor versi dari setidaknya browser web utama dan tanggal rilisnya yang disertakan dalam laporan saat mengacu pada "browser lama". Ini akan sangat membantu siapa pun saat "menilai kerentanan dalam implementasi tertentu menggunakan pustaka yang terpengaruh". Misalnya, jika saya melihat bahwa pengguna harus menggunakan browser dari tahun 2011, saya akan menandai masalah tersebut sebagai "tidak terpengaruh" di SCA dalam satu detik. Banyak waktu yang dihemat.
• Versi Koa yang terpengaruh akan dicantumkan di halaman kerentanan .

Omong-omong, Sonatype juga menyebutkan bahwa mereka memiliki beberapa pemeriksaan keren dalam penawaran komersial mereka yang, misalnya, melakukan pemeriksaan aktual pada tingkat kode untuk melihat apakah aplikasi terpengaruh oleh kerentanan yang dilaporkan. Kedengarannya bagus, dan mengingat sifat fiksi ilmiah tentang bagaimana skor kerentanan dihitung untuk perpustakaan, pemeriksaan semacam ini harus dilakukan untuk mengurangi beban tim teknik, terutama jika keadaan terus berlanjut seperti ini.

Kesimpulan

Itu cukup banyak semua pembaruan yang saya miliki. Saya senang telah menghubungi Sonatype karena mereka sangat profesional dan ramah. Sangat menyenangkan bekerja dengan mereka dalam hal ini.

Mengenai XSS di Koa: itu adalah sesuatu yang seharusnya tidak ada dari kita yang khawatir selama beberapa tahun sekarang.