Kekesalan saya sangat tinggi karena hal itu baru saja terjadi lagi. Jika Anda telah membaca analisis saya sebelumnya yang berjudul CVE-2022–29622: (Dalam)Analisis Kerentanan , Anda mungkin menduga apa yang saya maksud. Cerita yang sama, korban yang berbeda. Namun, tanggal penting dalam kasus ini. Analisis kekebalan saya sebelumnya adalah dari tahun 2022, hari ini saya akan menganalisis masalah lain dari tahun 2018.

Anda mungkin bertanya: "Mengapa Anda harus berurusan dengan sesuatu dari tahun 2018?" Pertanyaan yang bagus! Karena saya baru saja mengaktifkan Dependency Track untuk menarik informasi kerentanan dari OSS Index Sonatype.

Hari ini saat saya menelusuri SCA untuk melihat apakah kami memiliki komponen yang rentan, dan jika ada, prioritaskan pekerjaan perbaikan. Saya menemukan sesuatu yang sangat mengejutkan. Koa.JS memiliki kerentanan kritis?! Setelah seperti biasa “#FFS, seluruh minggu saya perlu diatur ulang.”, Saya seperti: “Tarik napas dalam-dalam dan lihat tentang apa ini. Anda ingat apa yang terjadi terakhir kali ... "

Dan begitulah yang saya lakukan. Pertama-tama, judulnya memperjelas bahwa “masalah” ditemukan pada tahun 2018. Sekarang, mengapa saya memiliki kerentanan di perpustakaan yang masih dipertahankan dan saya terus meningkatkan ke versi terbaru? Pada titik ini bagian investigasi otak saya bekerja.

Apa yang kita ketahui/lihat saat ini?

1. Diduga ada kerentanan di Koa pada tahun 2018 dengan tingkat keparahan Kritis ditetapkan
2. Menurut Sonatype OSS Index dan Dependency Track, masalah ini memengaruhi saya pada tahun 2022 saat menjalankan Koa versi terbaru

• Versi perpustakaan Koa.JS mana yang terpengaruh oleh "kerentanan"
• Jika "kerentanan" hadir di Koa.JS terbaru

Analisis Masalah

Mari kita lihat apa itu "kerentanan". Izinkan saya menautkan dengan cepat masalah terkait #1250 dari GitHub di sini. Saya hanya akan menyalin-tempel contoh (PoC?) Di bawah ini agar kami dapat menganalisisnya.

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

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

app.listen(3000);

“Sebagai pengembang aplikasi web atau layanan web, saya dapat mengarahkan browser Anda ke mana pun yang saya inginkan jika Anda mengunjungi situs web saya.”

Itulah arti kode di atas. Di PoC di atas tidak ada vektor serangan yang disajikan untuk aktor jahat untuk mengeksploitasi apa pun.

Jika Anda ingin memberikan "PoC" yang tepat untuk non-kerentanan ini (ya, saya baru saja mengatakannya), akan terlihat seperti ini:

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

Berbicara tentang kerentanan XSS, jika apa pun yang saya masukkan sebagai nilai vectorparameter ditampilkan dalam konteks HTML dengan tidak aman, aplikasi yang saya terapkan akan rentan terhadap Cross Site Scripting. (Lebih lanjut tentang ini nanti)

Memperbesar bagaimana Sonatype menyajikan ini dan menganalisisnya sedikit lebih jauh:

“Buka Redirect yang mengarah ke Cross-Site Scripting”? 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. Yang pertama, tidak ada vektor serangan, jadi tidak ada pengalihan terbuka. PoC saya memiliki vektor serangan, tidak ada pemfilteran, sehingga ada pengalihan terbuka. Tapi, seperti yang Anda lihat, ada atau tidaknya pengalihan terbuka bergantung pada saya, pengembangnya, dan bukan Koa.JS. Lebih bagusnya lagi, ada redirect atau tidak juga tergantung saya. Apakah saya menyertakan masukan yang disediakan pengguna sebagai/dalam URL pengalihan dengan cara yang tidak aman juga terserah saya. Kerentanan Koa.JS apa yang sedang kita bicarakan? Secara teknis, tidak ada kerentanan dan seseorang masih memberikan tingkat keparahan Kritis padanya. Tidak sepenuhnya profesional.

Bagaimanapun, mari kita "eksploitasi" kata "kerentanan" yang diterapkan oleh PoC yang tepat. Harap dicatat bahwa saya harus mengubah port layanan dari 3000 ke 4444 karena saya sudah mendengarkan sesuatu di port 3000.

Kita bisa melihat Locationrespon header memiliki nilai javascript:alert(1). Kemudian, browser dialihkan ke…

Hah, aku aman! Tidak ada kotak peringatan yang muncul. Ya, saya bisa memasukkan https://google.comnilai vectorparameter kueri dan dialihkan ke Google, jadi aplikasi saya (PoC) rentan terhadap pengalihan terbuka, tetapi bukan karena Koa, tetapi karena saya meneruskan data pengguna yang tidak difilter ke ctx.redirect. Itu bukan sesuatu yang saya khawatirkan, saya tidak akan pernah melakukan ini.

Hal penting yang perlu diperhatikan dari komentar masalah di GitHub adalah sebagai berikut:

Masalahnya berasal dari fakta bahwa Koa mencetak hyperlink HTML di badan respons pengalihan dan itu dapat memicu serangan skrip lintas situs.

Ah, itu lebih masuk akal! Mari kita lihat apakah itu masih terjadi.

Tidak, bukan itu masalahnya lagi. Tidak ada badan tanggapan. Saya kira saya dapat menyimpulkan bahwa "kerentanan" ini tidak memengaruhi saya. Saya bisa pergi dan menandainya sebagai false positive di Dependency Track.

Analisis Konteks

Saya mengusulkan "Analisis Konteks" untuk diadopsi oleh semua profesional keamanan dan dilakukan sebelum melaporkan "masalah". Biarkan ini menjadi contoh lain dan tunjukkan cara melakukannya. (Saya tetap menyarankan Anda membaca CVE-2022–29622: (In)vulnerability Analysis karena ini menjelaskan pentingnya konteks jauh lebih baik.)

1. Koa.JS out-of-the-box tidak mengarahkan Anda ke mana pun. Oleh karena itu, ada dan tidak ada "Open Redirect" seperti yang dinyatakan oleh Sonatype OSS Index.
2. Berdasarkan “PoC” yang disediakan di GitHub, ada peluang bagi pengembang untuk melakukan sesuatu yang bodoh yang dapat mengarah ke XSS. Tapi, lihat # 1 di atas. Koa.JS tidak melakukan redirect sendiri. Lihat #2 di bawah.
3. Pengembang harus mengimplementasikan aplikasinya dengan cara yang tidak aman agar "kerentanan" yang dilaporkan ada. Ini cukup berarti bahwa Koa.JS meskipun bisa melakukan lebih baik, Anda tidak bisa menyebutnya rentan. Itu tidak pantas secara kontekstual. Kerentanan tersebut hanya dapat hadir dalam aplikasi web yang diimplementasikan secara tidak aman .

Biarkan saya memberi Anda contoh bagaimana situasi seperti ini paling baik ditangani. Lihat masalah ini yang saya serahkan ke Swagger Parser dan bagaimana hal itu dikomunikasikan. Mari kita menganalisis laporan masalah:

1. Judulnya mengatakan “Insecure Resolver Behavior”. Saya tidak berbicara tentang LFI (Local File Inclusion) di judulnya. Ini karena meskipun ada potensi penyertaan file lokal JIKA SAYA MENGACAUKAN HAL-HAL, itu benar-benar tergantung pada saya sebagai pengembang untuk mengetahui apa yang sedang saya kerjakan dan bagaimana saya mengerjakannya. Perilaku default (mungkin masih) tidak aman. Tapi, perpustakaan itu sendiri, tanpa keterlibatan saya tidak akan berbuat apa-apa.
2. Kemudian, saya dengan jelas menyatakan versi perpustakaan mana yang saya bicarakan. Saya membuat konteksnya lebih jelas dengan mencantumkan kondisi di mana perilaku default perpustakaan yang tidak aman akan memengaruhi aplikasi. Ini memperjelas bahwa perpustakaan itu sendiri tidak rentan, tetapi memiliki perilaku tidak aman yang dapat diperbaiki untuk membantu pengembang.
3. Jadi sekarang setelah konteksnya diatur, saya memberikan PoC yang berfungsi, cuplikan kode yang rentan (yang saya tulis sebagai PoC, itu bukan bagian dari Swagger Parser!) Dan hasil nyata dari eksploitasi aplikasi/layanan rentan yang menggunakan perpustakaan dengan tidak aman.
4. Saya melakukan beberapa penyelidikan dan menemukan bahwa sebagai pengembang saya benar-benar dapat mengonfigurasi perpustakaan dengan cara yang mengurangi masalah. (sampai batas tertentu) saya membagikan ini dengan para devs. Jika tidak ada yang lain, setidaknya mereka dapat memperbarui dokumentasi untuk meningkatkan kesadaran.
5. Saya memberikan konteks tambahan, analisis, dan contoh bagaimana hal-hal dapat diperbaiki.

Kesimpulan

Pertama-tama, Sonatype harus bekerja lebih baik dengan Indeks OSS dan memastikan informasi versi tersedia untuk setiap kerentanan dalam database. Itu minimal. (Poin bonus untuk menghapus entri khusus ini dari database seluruhnya.)

Saya menduga Dependency Track menderita FOMO, oleh karena itu, bersedia melaporkan masalah murni berdasarkan kecocokan nama komponen jika nomor versi tidak tersedia. Saya memahami sampai batas tertentu bahwa mereka tidak akan mengambil risiko kehilangan kerentanan kritis. Masalah dengan perilaku ini (positif palsu) adalah tidak mendorong penerapan Analisis Komposisi Perangkat Lunak. Ini akan menakuti pengembang seperti positif palsu dari analisis kode statis. Kontraproduktif.

Konteks! Konteks berdarah, semuanya! Saya melamar:

1. "Analisis Konteks" untuk diadopsi oleh semua profesional keamanan dan dilakukan sebelum melaporkan "masalah"
2. Membedakan "perilaku tidak aman" dari "kerentanan"
3. Memahami perbedaan antara pustaka perangkat lunak dan aplikasi/layanan