Rumah  >  Artikel  >  Java  >  Ancaman berterusan: Mengapa kelemahan utama seperti Logell dan Springell kekal penting

Ancaman berterusan: Mengapa kelemahan utama seperti Logell dan Springell kekal penting

WBOY
WBOYasal
2024-08-31 13:02:02668semak imbas

The persistent threat: Why major vulnerabilities like Logell and Springell remain significant

Sebagai pembangun, kami sentiasa menyesuaikan ciri, pembetulan dan tarikh akhir. Namun, isu terselindung telah diabaikan secara mengejutkan: penggunaan berterusan versi Log4j dan Spring Framework yang terdedah dalam banyak projek. Walaupun pendedahan berprofil tinggi terhadap kelemahan Log4Shell dan Spring4Shell, sebilangan besar aplikasi yang mengejutkan masih berjalan pada bom masa yang berdetik ini. Ini bukan hanya kesilapan kecil — ia adalah risiko besar. Kami adalah pembina di hati, tetapi sebahagian daripada pembinaan adalah memastikan struktur kami selamat. 

Dilema pemaju

Sebagai pembangun, kami sentiasa mengimbangi pengeluaran ciri baharu dan mengekalkan projek serta ciri sedia ada. Ia adalah tindakan mengimbangi yang memerlukan masa dan lebar jalur kognitif penuh kita. Menjejaki kebergantungan setiap projek sambil memastikan ia dikemas kini boleh terasa seperti satu perjuangan yang sukar, terutamanya apabila tekanan diberikan untuk menyampaikan fungsi baharu. Di tengah-tengah tindakan juggling ini, kelemahan kritikal seperti Log4Shell dan Spring4Shell kadang-kadang boleh jatuh melalui retakan, bukan kerana kecuaian tetapi disebabkan oleh jumlah tugas yang banyak yang kami uruskan setiap hari. Walau bagaimanapun, adalah penting untuk menyedari bahawa keselamatan dan keselamatan aplikasi yang menarik adalah aspek penting dalam pembangunan perisian pada masa kini.

Keadaan semasa Log4shell

Ingat Log4Shell? Kerentanan jahat dalam Apache Log4j ditemui pada tahun 2021 yang boleh membenarkan penyerang menjalankan kod pada pelayan anda dengan mengelog rentetan khas? Penyerang boleh menggunakan carian JNDI dengan protokol LDAP untuk menyuntik fail kelas yang telah dikompilasi dan melaksanakan kod hasad. Malah dalam versi Java yang lebih baharu, kelemahan ini boleh menyebabkan kerosakan akibat serangan penyahserialisasian. Kerumitan serangan kerentanan kritikal ini dianggap sangat rendah, yang menjadikan ancaman lebih tinggi daripada biasa. Semak catatan blog kami untuk butiran penuh isu tersebut.

Lebih daripada 20% syarikat masih terdedah kepada Log4shell.

Hari ini, banyak syarikat masih mempunyai versi perpustakaan Log4j yang lapuk dan terdedah dalam salah satu projek mereka. Daripada semua pelanggan Snyk yang mengimbas kod pengeluaran mereka untuk mencari kelemahan, 21% masih mempunyai projek yang terdedah kepada Log4Shell. Ini bermakna lebih 60k projek masih berisiko dilanggar oleh kelemahan yang didedahkan dan diperbaiki sejak 2 tahun lalu. Itu besar! Mengetahui bahawa syarikat-syarikat ini sudah menggunakan alat keselamatan dan secara aktif mengurangkan isu keselamatan yang mereka hadapi, bilangan sebenar versi log4j yang terdedah di alam liar akan jauh lebih tinggi daripada itu. Pemikiran itu sahaja bukan sahaja menakutkan tetapi juga sangat mengganggu.

Spring4Shell di alam liar

Satu lagi contoh terkenal ialah Spring4Shell, yang telah didedahkan pada Mac 2022. Kerentanan dalam spring-beans juga boleh membawa kepada pelaksanaan kod jauh yang berniat jahat. Walaupun kerumitan serangan adalah rendah, dan terdapat eksploitasi untuk kes tertentu, kesannya kurang ketara berbanding Log4Shell. Lihat catatan blog khusus untuk butiran lanjut.

Dengan memperluaskan kerentanan ini kepada Glassfish dengan eksploitasi baharu pada April 2022, pasukan Snyk membuktikan bahawa kerentanan ini sangat ketara dan boleh disalahgunakan dalam banyak lagi kes di luar eksploitasi pertama untuk kucing jantan.

Sama seperti Log4Shell, kami mendapati Spring4Shell masih boleh digunakan di alam liar. Kira-kira 35% pelanggan kami masih mempunyai kelemahan dalam salah satu projek mereka. Walaupun risiko pelanggaran Spring4Shell tidak begitu ketara seperti Log4Shell, pasukan Snyk menunjukkan pelbagai potensi eksploitasi dengan mengenal pasti dan membangunkan bukti eksploitasi konsep (POC) untuk Glassfish. Ini membuktikan bahawa bahaya yang kelihatan lebih kecil masih boleh membawa kepada kelemahan keselamatan yang ketara. Hakikat bahawa tiada eksploitasi diterbitkan lagi tidak membayangkan aplikasi tidak boleh dilanggar oleh kelemahan!

Selain itu, ia menunjukkan bahawa banyak aplikasi Spring bergantung pada versi rangka kerja yang lebih lama dan lapuk, dan mengemas kini serta memberi perkhidmatan kepada aplikasi sedia ada dianggap tidak penting. Walau bagaimanapun, jauh di lubuk hati, kami tahu ini adalah bom jangka yang boleh meletup bila-bila masa.

Wakeup call kepada semua yang menyelenggara aplikasi

Mari kita pastikan ini terus terang dan tepat sasaran. Kita semua tahu perasaan bangga apabila kod kita akhirnya berjalan tanpa sebarang halangan, dan perkara terakhir yang kita mahu lakukan ialah kembali dan mengacaukannya, terutamanya untuk sesuatu yang bodoh seperti mengemas kini perpustakaan. Tetapi inilah perkaranya: kelemahan Log4Shell dan Spring4Shell itu tidak akan membaiki sendiri. Dan secara jujur, ia bukan sahaja pepijat kecil yang boleh kita abaikan. Mereka menganga lubang di dinding aplikasi kami. Jika anda masih mempunyai kelemahan seperti Log4Shell atau Spring4Shell dalam landskap anda, anda tidak semestinya terdedah kepada serangan keterukan tinggi!

Snyk boleh membantu anda dengan ini dengan mengesan dan membantu menangani kelemahan keselamatan dalam aplikasi. Ia disepadukan dengan aliran kerja pembangunan dalam beberapa cara, seperti melalui repositori Git, Antara Muka Baris Perintah (CLI) atau saluran paip Integrasi Berterusan (CI) sedia ada, membolehkan pembangun mengenal pasti risiko keselamatan pada awal kitaran pembangunan sebelum ia bertukar menjadi masalah yang lebih besar. Pendaftaran adalah percuma, membenarkan akses segera kepada ciri-cirinya. Walau bagaimanapun, nilai sebenar terletak pada cara kelemahan yang ditemui diurus dan diselesaikan selepas pengenalan.

Kita perlu bertanggungjawab di sini. Ia bukan hanya tentang mencari tampung cepat atau berharap kemas kini mudah akan berjaya. Kadangkala, kita perlu membuat panggilan keras untuk mengalih keluar atau menggantikan perpustakaan yang terdedah. Ya, ia mungkin melambatkan kita sedikit, dan ia bukan bahagian yang paling menarik dalam tugas kita, tetapi ia penting. Ini tentang memastikan kod kami kukuh, bukan sahaja untuk hari ini tetapi untuk jangka masa panjang.

Jadi, jangan tunggu orang lain selesaikan masalah ini. Dengan alatan yang betul, kita boleh mengesan kelemahan ini lebih awal, tetapi kita perlu bertindak. Terpulang kepada kami untuk menguatkan pertahanan kami, menambal kelemahan tersebut dan memastikan aplikasi kami selamat dan kukuh. Mari kita lakukannya, bukan hanya sebagai pengekod, tetapi sebagai orang yang menyokong kerja mereka, memastikan kerja itu selamat.

Atas ialah kandungan terperinci Ancaman berterusan: Mengapa kelemahan utama seperti Logell dan Springell kekal penting. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan:
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn
Artikel sebelumnya:Memahami ahli statikArtikel seterusnya:Memahami ahli statik