Seberapa amankah dependensi Open-source JavaScript Anda?

Pengembang JavaScript modern menyukai npm .GitHub dan npm registry adalah tempat pilihan pertama bagi para pengembang untuk menemukan sebuah package (paket) tertentu. Modul open-source menambah produktivitas dan efisiensi dengan menyediakan para pengembang berbagai fungsi yang dapat Anda gunakan kembali dalam proyek Anda. Ini adil untuk mengatakan bahwa jika tidak untuk paket-paket open source ini, sebagian besar kerangka kerja hari ini akan tidak ada dalam bentuk mereka saat ini.

Aplikasi tingkat perusahaan yang lengkap misalnya, mungkin mengandalkan ratusan bahkan ribuan paket. Dependensi biasa termasuk dependensi yang langsung, dependensi dalam proses pengembangan, dependensi yang dibundel, dependensi dalam proses produksi, dan pilihan dependensi. Itu bagus karena semua orang mendapatkan yang terbaik dari ekosistem open source.

Namun, salah satu faktor yang terlewatkan adalah jumlah risiko yang terlibat. Meskipun modul third-party (pihak ketiga) ini sangat berguna dalam wilayah proses pengembangan mereka, mereka juga memperkenalkan beberapa risiko keamanan ke dalam aplikasi Anda.

Apakah Pustaka Open Source itu Rentan?

OSS dependensi memang rentan terhadap exploit dan membahayakan. Mari kita lihat beberapa contoh:

Kerentanan (vulnerability) ditemukan baru-baru ini dalam paket yang disebut eslint-scope yang merupakan dependensi beberapa paket JavaScript populer seperti babel-eslint dan webpack. Akun pengelola paket membahayakan, dan peretas menambahkan beberapa kode berbahaya ke dalamnya. Untungnya, seseorang cukup cepat menemukan exploit tersebut bahwa kerusakan itu dilaporkan pada beberapa pengguna dalam jumlah yang sedikit.

Moment.js, yang merupakan salah satu pustaka yang paling sering digunakan untuk mengurai dan menampilkan tanggal dalam JavaScript, baru-baru ini ditemukan memiliki kerentanan dengan skor keparahan 7,5. Exploit membuatnya rentan terhadap serangan ReDoS. Patch dirilis dengan cepat, dan mereka mampu memperbaiki masalah dengan agak cepat.

Tapi bukan itu saja. Banyak exploit baru ditemukan setiap minggu. Beberapa dari exploit tersebut terungkap kepada publik, tetapi yang lain menjadi berita utama hanya setelah pelanggaran serius.

Jadi bagaimana kita mengurangi risiko ini? Dalam artikel ini, saya akan menjelaskan beberapa praktik terbaik untuk standar industri yang dapat Anda gunakan untuk mengamankan dependensi open-source Anda.

1. Melacak Dependensi Aplikasi Anda

Berbicara secara logis, ketika jumlah dependensi meningkat, risiko berakhir dengan paket yang rentan juga dapat meningkat. Hal ini berlaku sama untuk dependensi yang langsung dan tidak langsung. Meskipun tidak ada alasan bahwa Anda harus berhenti menggunakan paket open source, selalu ada baiknya untuk tetap melacaknya.

Dependensi ini mudah ditemukan dan dapat sesederhana seperti menjalankan npm ls di direktori root aplikasi Anda. Anda dapat menggunakan argumen -prod yang menampilkan semua dependensi untuk proses produksi dan argumen -long untuk ringkasan setiap deskripsi paket.

Selanjutnya, Anda dapat menggunakan layanan untuk mengotomatiskan proses manajemen dependensi yang menawarkan pemantauan secara realt-time dan pengujian pembaruan secara otomatis untuk dependensi Anda. Beberapa fasilitas yang dikenal termasuk GreenKeeper, Libraries.io, dll. Fasilitas ini menyusun daftar dependensi yang Anda gunakan saat ini dan melacak informasi yang relevan mengenai mereka.

2. Menyingkirkan Paket yang Tidak Anda Butuhkan

Dengan berlalunya waktu dan perubahan dalam kode Anda, ada kemungkinan bahwa Anda akan berhenti menggunakan beberapa paket sekaligus dan bukannya menambahkan yang baru. Namun, para pengembang cenderung tidak menghapus paket lama saat mereka berjalan.

Seiring waktu, proyek Anda mungkin mengakumulasi banyak dependensi yang tidak digunakan. Meskipun ini bukan risiko keamanan secara langsung, dependensi ini hampir pasti menambah timbulnya serangan pada proyek Anda dan menyebabkan kekacauan yang tidak perlu dalam kode. Seorang penyerang mungkin dapat menemukan celah dengan memuat paket lama terinstal tetapi yang memiliki tingkat kerentanan yang lebih tinggi, sehingga meningkatkan potensi kerusakan yang dapat ditimbulkannya.

Bagaimana Anda memeriksa dependensi yang tidak terpakai? Anda dapat melakukan ini dengan bantuan fasilitas bernama depcheck. Depcheck memindai seluruh kode Anda untuk perintah requires dan import. Kemudian mengkorelasikan perintah ini dengan paket yang diinstal atau yang disebutkan dalam package.json Anda dan memberi Anda laporan. Perintah ini juga dapat dimodifikasi menggunakan perintah flag yang berbeda, sehingga membuatnya lebih mudah untuk mengotomatiskan pemeriksaan dependensi yang tidak digunakan.

Instal depcheck dengan:

1

npm install -g depcheck

3. Temukan dan Perbaiki Kerentanan Keamanan yang Penting

Hampir semua poin yang dibahas di atas terutama berkaitan dengan potensi masalah yang mungkin Anda hadapi. Tetapi bagaimana dengan dependensi yang Anda gunakan saat ini?

Berdasarkan penelitian terbaru, hampir 15% dari paket saat ini termasuk kerentanan yang diketahui, baik dalam komponen atau dependensi. Namun, kabar baiknya adalah bahwa ada banyak fasilitas yang dapat Anda gunakan untuk menganalisis kode Anda dan menemukan risiko keamanan dari kode open-source dalam proyek Anda.

Fasiltar yang paling nyaman adalah npm npm audit. Audit adalah skrip yang dirilis dengan npm versi ke 6. Platform keamana Node awalnya mengembangkan npm audit, dan npm register kemudian mendapatkannya. Jika Anda penasaran ingin tahu semua hal tentang apa itu npm audit, berikut adalah kutipan dari blog resmi:

Audit keamanan adalah penilaian dependensi paket untuk kerentanan keamanan. Audit keamanan membantu Anda melindungi pengguna paket Anda dengan memungkinkan Anda menemukan dan memperbaiki kerentanan yang diketahui dalam dependensi. Perintah npm audit mengirimkan deskripsi dependensi yang dikonfigurasikan dalam paket Anda ke registri default Anda dan meminta laporan kerentanan yang diketahui.

Laporan yang dihasilkan biasanya terdiri dari rincian berikut: nama paket yang terpengaruh, keparahan kerentanan dan deskripsi, path, dan informasi lainnya, dan, jika tersedia, perintah untuk menerapkan patch untuk menyelesaikan kerentanan. Anda bahkan bisa mendapatkan laporan audit di JSON dengan menjalankan npm audit --json.

Selain itu, npm juga menawarkan bantuan tentang bagaimana bertindak berdasarkan laporan tersebut. Anda dapat menggunakan npm audit fix untuk memperbaiki masalah yang telah ditemukan. Perbaikan ini biasanya dilakukan menggunakan peningkatan panduan atau melalui patch open-source.

Jangan ragu untuk merujuk kepada dokumentasi npm untuk informasi lebih lanjut.

4. Mengganti Pustaka yang Habis Dengan Alternatif yang Tersedia

Konsep keamanan open-source sangat bergantung pada jumlah mata yang mengawasi pustaka tertentu. Paket yang digunakan lebih aktif lebih diawasi dengan ketat. Oleh karena itu, ada kemungkinan yang lebih tinggi bahwa para pengembang mungkin telah mengatasi semua masalah keamanan yang dikenal dalam paket tertentu.

Mari kita ambil contoh. Di GitHub, ada banyak implementasi token web JSON yang dapat Anda gunakan dengan pustaka Node.js Anda. Namun, orang-orang yang tidak dalam masa pengembangan aktif bisa memiliki kerentanan yang kritis. Salah satu kerentanan tersebut, yang dilaporkan oleh Auth0, memungkinkan siapa pun membuat token "bertanda tangan" sendiri dengan muatan apa pun yang diinginkan.

Jika sebuah paket yang cukup populer atau digunakan dengan baik memiliki kecacatan ini, kemungkinan besar para pengembang akan menemukan dan melakukan proses patch dari kesalahannya. Tetapi bagaimana dengan proyek yang tidak aktif / terbengkalai? Kami akan membicarakannya di poin berikutnya.

5. Selalu Pilih Pustaka yang sedang dalam Pengembangan yang Aktif

Mungkin cara tercepat dan paling efisien untuk menentukan aktivitas paket tertentu adalah dengan memeriksa tingkat unduhannya pada npm. Anda dapat menemukannya di bagian Stats / Statistik di halaman paket npm. Anda juga dapat mengekstrak angka-angka ini secara otomatis menggunakan npm stats API atau dengan menelusuri statistik historis di npm-stat.com. Untuk paket dengan repositori GitHub, Anda harus memeriksa riwayat komit, pelacakan dari masalah, dan pull request yang relevan untuk pustaka.

6. Perbarui Dependensi secara Teratur

Ada banyak bug, termasuk sejumlah besar bug keamanan yang terus digali dan, dalam banyak kasus, segera lakukan proses patch. Tidak jarang melihat kerentanan yang dilaporkan baru-baru ini diperbaiki hanya pada cabang / versi terbaru dari proyek yang diberikan.

Sebagai contoh, mari kita lihat kerentanan Regular Expression Denial of Service (ReDoS) yang dilaporkan pada paket HMAC 'hawk' pada awal 2016. Bug di hawk ini dengan cepat diselesaikan, tetapi hanya dalam versi mayor terbaru, 4.x. Versi lama seperti 3.x banyak dilakukan patch belakangan meskipun mereka sama-sama berisiko.

Oleh karena itu, sebagai aturan umum, dependensi Anda cenderung tidak memiliki bug keamanan jika mereka menggunakan versi terbaru yang tersedia.

Cara termudah untuk mengonfirmasi jika Anda menggunakan versi terbaru adalah dengan menggunakan perintah npm outdated. Perintah ini mendukung flag -prod untuk mengabaikan setiap dependensi dev dan --json untuk membuat otomatisasi menjadi lebih sederhana.

Secara teratur memeriksa paket-paket yang Anda gunakan untuk memverifikasi tanggal modifikasi mereka. Anda dapat melakukan ini dengan dua cara: melalui npm UI, atau dengan menjalankan npm view <package> time.modified.

Kesimpulan

Kunci untuk mengamankan aplikasi Anda adalah memiliki kebiasaan mengutamaka keamanan dari awal. Dalam artikel ini, kami telah membahas beberapa praktik standar untuk meningkatkan keamanan komponen JavaScript Anda.

1. Gunakan dependensi open-source yang sedang dalam pengembangan yang aktif.
   
2. Perbarui dan pantau komponen Anda.
3. Meninjau kode Anda dan mencatat pengujian.
4. Hapus dependensi yang tidak diinginkan atau gunakan alternatif.
5. Gunakan fasilitas keamanan seperti npm audit untuk menganalisis dependensi Anda.

Jika Anda memiliki pemikiran tentang keamanan JavaScript, jangan ragu untuk membagikannya di komentar.