Saat ini, layanan web terus-menerus terkena berbagai serangan. Oleh karena itu, keamanan adalah sesuatu yang perlu diingat pada semua tahap siklus hidup proyek. Para penulis materi, terjemahan yang kami terbitkan hari ini, mengelola
repositori di GitHub yang berisi sekitar 80 rekomendasi untuk mengamankan aplikasi yang berjalan pada platform Node.js. Materi ini, berdasarkan banyak publikasi keamanan, memiliki lebih dari dua lusin rekomendasi mengenai Node.js dan beberapa tips umum. Selain itu, materi ini mencakup 10 kerentanan teratas dari daftar proyek OWASP.
1. Gunakan aturan untuk linter, yang bertujuan memeriksa keamanan kode
Rekomendasi
Selama pengembangan, gunakan plug-in berorientasi keamanan untuk linter, seperti
eslint-plugin-security . Ini memungkinkan Anda mengidentifikasi kerentanan dan masalah keamanan sangat dini - pada saat penulisan kode yang sesuai. Pendekatan ini membantu menemukan kelemahan dalam keamanan program. Di antara mereka adalah penggunaan perintah
eval , doa proses anak, impor modul dengan transfer ke perintah yang sesuai dari sesuatu yang berbeda dari string literal (katakanlah, string tertentu dibentuk berdasarkan data yang dikirim ke server oleh pengguna).
→
Berikut adalah beberapa bahan yang berguna tentang aturan linter
Adam Baldwin mengatakan hal berikut tentang linting: “Linter seharusnya bukan hanya alat yang dengan cermat mengikuti aturan mengenai jumlah ruang yang digunakan, titik koma, dan penggunaan perintah eval. ESLint menyediakan pengembang dengan platform yang kuat yang dapat mendeteksi dan menghilangkan berbagai pola yang berpotensi berbahaya dalam kode. Kami berbicara, misalnya, tentang ekspresi reguler, tentang memeriksa input pengguna, dan sebagainya. Saya percaya bahwa linter memberikan pengembang yang peduli tentang masalah keamanan alat baru yang kuat dan layak untuk diperhatikan. ”
Kemungkinan masalah
Apa yang tampak seperti cacat keamanan kecil selama pengembangan menjadi kerentanan serius dalam produksi. Selain itu, jika semua pengembang proyek tidak mengikuti aturan keamanan yang seragam ketika bekerja dengan kode, ini dapat menyebabkan kerentanan di dalamnya, atau, misalnya, penetrasi data rahasia ke dalam repositori publik.
2. Batasi jumlah permintaan server simultan
Rekomendasi
Serangan DoS sangat populer di kalangan penjahat dunia maya, dan itu relatif mudah dilakukan. Anda dapat menerapkan sistem untuk membatasi jumlah permintaan ke aplikasi menggunakan layanan eksternal, seperti penyeimbang beban cloud, firewall cloud, server nginx, atau, untuk aplikasi kecil yang tidak kritis, menggunakan middleware untuk membatasi jumlah permintaan seperti
tarif kilat -batas .
→
Berikut ini adalah materi tentang implementasi sistem untuk membatasi frekuensi permintaan ke server
Kemungkinan masalah
Aplikasi yang tidak menyediakan sistem untuk membatasi jumlah permintaan simultan dapat diserang, yang akan mengarah pada kegagalannya. Ini dinyatakan dalam kenyataan bahwa pengguna aplikasi semacam itu akan mengalami kesulitan bekerja dengannya atau tidak akan dapat berinteraksi dengannya sama sekali.
3. Hapus informasi rahasia dari file konfigurasi atau mengenkripsi mereka
Rekomendasi
Jangan pernah menyimpan data sensitif dalam teks biasa dalam file konfigurasi atau dalam kode. Sebagai gantinya, gunakan sistem manajemen data sensitif seperti produk Vault atau sistem Kubernetes / Docker Secrets, atau gunakan variabel lingkungan untuk menyimpan data tersebut. Data rahasia yang disimpan dalam sistem kontrol versi harus dienkripsi, tindakan harus diambil untuk penyimpanan dan penggunaannya yang aman. Di antara langkah-langkah tersebut adalah penggunaan kunci dinamis, penggunaan tanggal kedaluwarsa kata sandi, audit keamanan, dan sebagainya. Gunakan sistem untuk memverifikasi kode sebelum melakukan atau sebelum mengirimnya ke repositori untuk mencegah pengiriman data sensitif secara tidak sengaja ke repositori publik.
→
Berikut ini materi tentang mengelola data sensitif
Kemungkinan masalah
Bahkan jika kode disimpan dalam repositori tertutup, suatu hari, secara tidak sengaja, kode tersebut mungkin tersedia untuk umum. Pada titik ini, semua data rahasia yang disimpan di dalamnya akan menjadi domain publik. Akibatnya, akses pihak ketiga ke repositori dengan kode secara tidak sengaja akan menyebabkan mereka mendapatkan akses ke sistem yang terkait dengannya (database, API, layanan, dan sebagainya).
4. Mencegah kerentanan injeksi kode
Rekomendasi
Untuk mencegah injeksi SQL / NoSQL dan serangan serupa lainnya, selalu gunakan perpustakaan ORM / ODM atau mekanisme DBMS yang ditujukan untuk pembersihan data, atau mendukung kueri parameterisasi yang dinamai atau diindeks, dan memeriksa apa yang datang dari pengguna. Jangan pernah gunakan, untuk menyematkan nilai-nilai tertentu dalam teks kueri, hanya templat string JavaScript, atau penggabungan string, karena pendekatan ini membuka aplikasi Anda ke berbagai kerentanan. Semua pustaka terhormat untuk Node.js yang digunakan untuk bekerja dengan data (misalnya,
Sequelize ,
Knex ,
luwak ) mengandung perlindungan
bawaan terhadap serangan dengan
menyuntikkan kode.
→
Ini adalah materi tentang pencegahan injeksi menggunakan perpustakaan ORM / ODM
Kemungkinan masalah
Penggunaan data yang tidak diverifikasi dan tidak bersih yang diterima dari pengguna dalam kueri dapat menyebabkan serangan dengan memperkenalkan operator ketika bekerja dengan database NoSQL seperti MongoDB. Jika Anda tidak menggunakan sistem pembersihan data atau pustaka ORM saat bekerja dengan database SQL, ini akan mengarah pada kemungkinan serangan oleh injeksi SQL, yang menciptakan lubang keamanan besar dalam aplikasi.
5. Hindari serangan DoS dengan secara eksplisit mengatur kondisi untuk penghentian proses yang abnormal
Rekomendasi
Proses Node macet ketika terjadi kesalahan yang tidak ditangani. Tetapi dalam banyak rekomendasi yang mencerminkan praktik terbaik untuk Node, direkomendasikan agar proses dihentikan bahkan ketika kesalahan telah dicegat dan diproses. Express, misalnya, akan macet ketika kesalahan asinkron terjadi - kecuali jika rute dibungkus dengan ekspresi
catch . Fakta ini menawarkan penyerang peluang yang sangat menarik. Mereka, setelah menemukan bahwa ketika permintaan tertentu tiba, proses macet, mulai mengirimkan permintaan seperti itu ke sana. Tidak ada rekomendasi yang akan menyelesaikan masalah ini dalam satu kali kejadian, namun, beberapa trik dapat mengatasinya. Jadi, pada akhir proses karena kesalahan tidak tertangani, Anda harus memberi tahu administrator, memberikan pemberitahuan semacam itu prioritas tertinggi yang penting. Penting untuk memeriksa apa yang datang ke proses dalam permintaan dan untuk menghindari situasi penghentian proses yang tidak normal karena permintaan yang, secara tidak sengaja atau sengaja, terbentuk secara tidak benar. Semua rute harus dibungkus dengan ekspresi
catch dan sistem harus dikonfigurasi sehingga, jika permintaan adalah penyebab kesalahan, proses tidak akan macet (sebagai lawan dari apa yang terjadi di tingkat aplikasi global).
Kemungkinan masalah
Mari kita menganalisis situasi berikut ini. Ada banyak aplikasi Node.js. Apa yang terjadi jika kami mulai mengirimi mereka permintaan POST dengan JSON kosong sebagai badan permintaan? Ini akan menyebabkan banyak aplikasi ini macet.
Sekarang, jika kita memainkan peran penjahat dunia maya, agar kita menjaga aplikasi agar tidak macet, itu akan cukup untuk terus mengirimi mereka permintaan yang sama.
6. Konfigurasikan header respons HTTP untuk meningkatkan keamanan proyek
Rekomendasi
Aplikasi harus menggunakan header HTTP yang berorientasi keamanan untuk mencegah penyerang menggunakan teknik serangan umum seperti cross-site scripting (XSS), clickjacking, dan lainnya. Menyesuaikan header mudah menggunakan modul khusus seperti
helm .
→
Ini adalah materi tentang menggunakan header yang aman
Kemungkinan masalah
Jika header HTTP aman tidak digunakan, penyerang akan dapat melakukan serangan terhadap pengguna aplikasi Anda, yang mengarah pada kerentanan besar.
7. Terus menerus, secara otomatis, periksa proyek Anda untuk penggunaan dependensi rentan di dalamnya
Rekomendasi
Dalam ekosistem NPM, proyek dengan banyak dependensi sangat umum. Dependensi harus selalu dikontrol, mengingat ditemukannya kerentanan baru. Gunakan alat seperti
npm audit ,
nsp, atau
snyk untuk mendeteksi, memantau, dan memperbaiki dependensi yang rentan. Sematkan alat ini di sistem integrasi berkelanjutan Anda. Ini akan memungkinkan Anda untuk mendeteksi dependensi yang rentan sebelum mereka mulai berproduksi.
→
Ini adalah materi tentang keamanan ketergantungan proyek
Kemungkinan masalah
Seorang penyerang dapat menentukan kerangka kerja web yang digunakan dalam proyek dan melakukan serangan terhadap semua kerentanan yang diketahui.
8. Cobalah untuk tidak menggunakan modul crypto Node.js standar untuk pemrosesan kata sandi, gunakan Bcrypt sebagai gantinya
Rekomendasi
Kata sandi atau data sensitif lainnya (misalnya, kunci API) harus disimpan dengan memprosesnya dengan fungsi kriptografis menggunakan "garam", seperti Bcrypt. Layak untuk menggunakan sesuatu yang persis sama, dan bukan modul
crypto Node.js standar untuk alasan keamanan dan kinerja.
→
Ini adalah materi tentang Bcrypt
Kemungkinan masalah
Kata sandi atau beberapa data rahasia yang disimpan tanpa penerapan langkah-langkah yang sesuai untuk melindunginya rentan terhadap serangan brute force dan serangan kamus, yang, sebagai akibatnya, mengarah pada pengungkapan data tersebut.
9. Gunakan sistem pelarian karakter dalam data HTML, JS dan CSS yang dikirim ke pengguna
Rekomendasi
Jika beberapa data dikirim ke browser pengguna dari sumber yang tidak dipercaya, maka bahkan jika mereka hanya ditampilkan, data tersebut dapat menjadi kode yang dapat dieksekusi. Ini biasanya disebut sebagai cross-site scripting (XSS). Anda dapat mengurangi risiko serangan seperti itu dimungkinkan menggunakan perpustakaan khusus yang memproses data sehingga tidak dapat dieksekusi. Ini disebut pengodean atau perisai data.
→
Ini adalah materi tentang melindungi output
Kemungkinan masalah
Jika Anda tidak peduli tentang pelindung data, penyerang dapat, misalnya, menyimpan kode JavaScript berbahaya di basis data Anda, yang dapat dikirim ke klien tanpa perubahan dan diluncurkan.
10. Periksa data JSON yang datang ke server
Rekomendasi
Kontrol isi badan permintaan masuk, periksa apakah mereka sesuai dengan apa yang Anda harapkan dalam permintaan tersebut. Jika permintaan tidak seperti yang diharapkan, cepat hentikan memprosesnya. Untuk menghindari operasi yang memakan waktu dari penulisan kode verifikasi permintaan untuk setiap rute, Anda dapat menggunakan alat JSON ringan untuk validasi data, seperti
jsonschema atau
joi .
→
Ini adalah bahan untuk memeriksa data JSON yang masuk
Kemungkinan masalah
Jika server menerima permintaan apa pun dengan ramah tanpa memeriksa mereka dengan saksama, ini sangat meningkatkan permukaan serangan aplikasi dan menginspirasi penyerang untuk mencoba menemukan banyak dari mereka yang mengarah pada "crash" sistem.
11. Pertahankan token JWT yang masuk daftar hitam
Rekomendasi
Saat menggunakan token JWT (misalnya, jika Anda bekerja dengan
Passport.js ), secara default, tidak ada mekanisme standar untuk mencabut hak akses sistem untuk token yang sudah dikeluarkan. Bahkan jika Anda menemukan bahwa pengguna tertentu melakukan sesuatu yang jelas-jelas tidak normal, Anda tidak dapat, melalui mekanisme token, untuk memblokir aksesnya ke sistem, selama ia memiliki token yang valid. Masalah ini dapat dikurangi dengan menerapkan daftar hitam dari token yang tidak dipercaya, yang validasinya dilakukan pada setiap permintaan.
→
Ini adalah materi tentang token JWT yang masuk daftar hitam
Kemungkinan masalah
Token yang jatuh ke tangan yang salah dapat digunakan oleh penyerang. Dia akan dapat mengakses aplikasi dan menyamar sebagai pengguna biasa - pemilik token.
12. Batasi jumlah upaya login
Rekomendasi
Dalam aplikasi berbasis express, untuk melindungi dari serangan brute force dan serangan kamus, ada baiknya menggunakan middleware yang sesuai, seperti
express-brute . Demikian juga, Anda perlu melindungi rute penting seperti
/admin atau
/login . Perlindungan harus didasarkan pada analisis properti kueri, seperti nama pengguna yang digunakan dalam kueri atau pengidentifikasi lainnya, seperti parameter badan permintaan.
→
Ini adalah bahan untuk membatasi jumlah upaya login
Kemungkinan masalah
Jika aplikasi tidak membatasi jumlah upaya login, penyerang dapat secara otomatis mengirim permintaan login yang tidak terbatas ke sistem Anda, misalnya, mencoba untuk mendapatkan akses ke akun istimewa.
13. Jalankan Node.js sebagai pengguna non-root
Rekomendasi
Skenario yang sangat umum adalah ketika Node.js dijalankan sebagai pengguna root dengan hak istimewa yang tidak terbatas. Sebagai contoh, ini adalah bagaimana semuanya dikonfigurasi secara default di wadah Docker. Disarankan agar Anda membuat pengguna yang tidak memiliki hak akses root, dan menanamkannya dalam gambar Docker, atau memulai proses atas nama pengguna itu dengan memanggil wadah dengan bendera
-u username .
→
Ini adalah materi tentang meluncurkan Node.js sebagai pengguna non-root
Kemungkinan masalah
Jika Node.js dijalankan di bawah akun pengguna root, maka penyerang yang bisa menjalankan skrip di server mendapat kemungkinan tak terbatas di mesin lokal. Katakanlah itu dapat mengubah pengaturan
iptable dan mengarahkan lalu lintas ke komputernya sendiri.
14. Batasi jumlah data yang dikirim dalam permintaan menggunakan server proxy terbalik atau middleware
Rekomendasi
Semakin besar jumlah data dalam badan permintaan, semakin sulit bagi server berulir tunggal untuk memproses permintaan tersebut. Penggunaan permintaan besar memberi penyerang kesempatan untuk membanjiri server dengan pekerjaan yang tidak perlu tanpa mengirimnya sejumlah besar permintaan (yaitu, tanpa melakukan serangan DoS / DDoS). Anda dapat mengurangi risiko serangan semacam itu dengan membatasi ukuran isi permintaan yang masuk pada sistem perbatasan tertentu (pada firewall atau pada penyeimbang beban), atau dengan menyetel express
body-parser untuk menerima hanya paket yang berisi sejumlah kecil data.
→
Berikut ini materi tentang membatasi jumlah data yang dikirim dalam permintaan
Kemungkinan masalah
Jika Anda tidak membatasi jumlah data yang dikirim dalam permintaan, penyerang dapat memuat aplikasi dengan memproses permintaan besar. Pada saat ini, ia tidak akan dapat menyelesaikan tugas yang memang dirancang. Hal ini menyebabkan kinerja yang buruk dan membuat aplikasi rentan terhadap serangan DoS.
15. Hindari menggunakan fungsi eval dalam JavaScript
Rekomendasi
Fungsi
eval jahat karena memungkinkan Anda untuk mengeksekusi kode JS sewenang-wenang yang diberikan selama eksekusi program. Selain itu, ini jauh dari hanya bahwa kode ini dapat memperlambat aplikasi. Fungsi ini menimbulkan risiko keamanan yang serius, karena kode JS berbahaya yang dikirim ke server oleh penyerang bisa masuk ke dalamnya.
Selain itu, Anda harus menghindari Konstruktor
new Function . Fungsi
setTimeout dan
setInterval tidak perlu melewati kode JS yang dihasilkan secara dinamis.
→
Ini adalah hal
- hal tentang eval
Kemungkinan masalah
Jika seseorang menemukan cara untuk mentransfer kode JS berbahaya, dalam bentuk teks, fungsi
eval , atau mesin JS serupa lainnya, ia akan memiliki akses penuh ke halaman, ke segala sesuatu yang dapat dilakukan menggunakan JavaScript. Kerentanan ini sering dikaitkan dengan serangan XSS.
16. Jangan membebani aplikasi Node.js single-threaded dengan ekspresi reguler berbahaya
Rekomendasi
Ekspresi reguler, meskipun mudah, menimbulkan ancaman bagi aplikasi JavaScript secara umum, dan khususnya pada platform Node.js. Memproses dengan ekspresi reguler apa yang datang dari pengguna dapat membuat beban besar pada prosesor. Misalnya, memproses ekspresi reguler bisa sangat tidak efisien sehingga memeriksa sepuluh kata dapat memblokir siklus peristiwa selama beberapa detik dan membebani prosesor. Oleh karena itu, yang terbaik adalah menggunakan paket pihak ketiga untuk memeriksa data string, seperti
validator.js , daripada menulis ekspresi reguler Anda sendiri. Anda dapat menggunakan paket
safe-regex untuk mendeteksi pola
regex yang rentan.
→
Ini adalah materi regex anti-malware
Kemungkinan masalah
Ekspresi reguler yang ditulis dengan buruk dapat dikenakan jenis serangan DoS khusus, di mana loop peristiwa sepenuhnya diblokir. Misalnya, pada November 2017, ditemukan bahwa paket
moment populer rentan terhadap serangan semacam itu.
17. Hindari memuat modul menggunakan variabel
Rekomendasi
Hindari mengimpor file yang jalurnya ditentukan sebagai parameter, berdasarkan pertimbangan yang dengannya parameter ini dapat ditetapkan berdasarkan data dari pengguna. Aturan ini dapat diperluas untuk memasukkan di sini dan, secara umum, akses ke file (menggunakan
fs.readFile() ), dan akses ke sumber daya penting lainnya menggunakan parameter yang diterima dari pengguna. Menggunakan
eslint-plugin-security memungkinkan untuk mendeteksi pola tidak aman tersebut sangat awal.
→
Ini adalah materi tentang memuat modul yang aman
Kemungkinan masalah
Data yang dikirim ke server oleh penyerang mungkin ada di pengaturan yang bertanggung jawab untuk mengimpor file tertentu, di antaranya mungkin file berbahaya yang sebelumnya diunggah ke server. Data ini juga dapat digunakan untuk mengakses file sistem yang sudah ada di komputer.
18.
, (, ), «», . , (
cluster.fork() ), npm-, .
→
, , . — , , , .
19.
, , . , , , .
child_process.execFile , , , , , .
→
,
, , , , .
20.
express, , . , , ,
Error ( ). , , , - , .
→
, , , , , , .
21. npm Yarn
, -, (MFA, multi-factor authentication). npm Yarn , . , , , . , . , , npm, .
, ?
eslint, .
22. ,
- . , — , - . , ,
X-Powered-By , , . , ( , , Node.js express).
→
-
- . , , -, — . .
23.
, . — , Node.js.
,
OWASP .
- root- .
- ( SSH-).
- , , , . OWASP, .
- , . , .
- OAuth, OpenID, . Basic Authentication.
- . , ( — ), X , Y .
- — , — . , .
- , , . ( — GitHub, AWS, Jenkins, ).
Ringkasan
. , Node.js-.
Pembaca yang budiman! -, ?
