Web Security Basics Every Developer Must Know — txt1.ai

Oleh Marcus Chen, Insinyur Keamanan Senior di sebuah perusahaan fintech Fortune 500 dengan 12 tahun pengalaman dalam memperkuat aplikasi web yang memproses lebih dari $2 miliar dalam transaksi harian

Tiga tahun lalu, saya menyaksikan seorang pengembang junior mengunggah kode ke produksi pada pukul 4:47 sore di hari Jumat. Pada pukul 6:15 sore, pusat operasi keamanan kami menyala seperti pohon Natal. Kerentanan injeksi SQL dalam fitur pencarian yang terlihat tidak bersalah telah mengekspos 340.000 catatan pelanggan. Pelanggaran tersebut menghabiskan biaya kami sebesar $4,2 juta dalam perbaikan, denda regulasi, dan bisnis yang hilang. Pengembangnya? Seorang insinyur brilian yang hanya tidak mengetahui apa yang tidak dia ketahui tentang keamanan web.

Insiden itu mengubah cara saya mendekati pendidikan keamanan. Saya menyadari bahwa sebagian besar pengembang tidak sembrono—mereka hanya beroperasi dalam kekosongan pengetahuan. Program ilmu komputer mungkin hanya menghabiskan dua minggu untuk keamanan, jika Anda beruntung. Bootcamp sering kali sama sekali mengabaikannya. Namun, kami diharapkan untuk membangun benteng sementara hanya memahami cara menumpuk batu bata.

Saya telah menghabiskan dekade terakhir di jalur keamanan web, dari pengujian penetrasi hingga membangun kerangka kerja keamanan yang digunakan oleh tim beranggotakan lebih dari 200 pengembang. Saya telah melihat serangan berevolusi dari upaya skrip-kiddie yang kasar hingga operasi negara-bangsa yang canggih. Dan saya telah belajar bahwa dasar-dasarnya—hal-hal mendasar yang harus diinternalisasi oleh setiap pengembang—tidak banyak berubah seperti yang Anda pikirkan. Kuasai prinsip-prinsip inti ini, dan Anda akan mencegah 90% kerentanan yang saya lihat dalam kode produksi setiap hari.

Memahami Permukaan Serangan: Apa yang Sebenarnya Anda Lindungi

Ketika saya bertanya kepada pengembang tentang apa yang mereka lindungi, saya biasanya mendengar "data pengguna" atau "database." Itu tidak salah, tetapi tidak lengkap. Permukaan serangan Anda adalah setiap titik di mana aplikasi Anda menerima input, memproses data, atau berinteraksi dengan sistem eksternal. Ini adalah formulir login, ya, tetapi juga titik akhir API yang Anda tulis untuk penggunaan internal saja, fitur unggahan file di panel admin, dan bahkan pesan kesalahan yang Anda tampilkan kepada pengguna.

Izinkan saya memberikan contoh nyata dari pengalaman saya sendiri. Kami memiliki titik akhir API internal yang menerima payload JSON untuk pembaruan pengguna massal. Itu "hanya untuk internal"—tidak ada otentikasi yang diperlukan karena hanya dapat diakses dari VPN kami. Kecuali seseorang mengkonfigurasi terbalik proxy, dan tiba-tiba titik akhir itu terekspos ke internet selama kira-kira 18 jam sebelum kami menangkapnya. Dalam 18 jam itu, pemindai otomatis sudah menemukannya dan mencoba 2.847 vektor serangan yang berbeda.

Permukaan serangan mencakup setiap ketergantungan dalam package.json atau requirements.txt Anda. Ketika kerentanan Log4Shell muncul pada bulan Desember 2021, saya menghabiskan 72 jam berturut-turut membantu tim mengidentifikasi dan memperbaiki sistem yang terkena. Kerentanan itu tidak ada dalam kode yang kami tulis—itu ada dalam pustaka pencatatan yang merupakan ketergantungan dari ketergantungan dari ketergantungan. Permukaan serangan Anda meluas melalui seluruh pohon ketergantungan Anda, yang untuk aplikasi Node.js biasa mungkin mencakup lebih dari 800 paket.

Pikirkan tentang batas kepercayaan aplikasi Anda. Di mana data yang tidak tepercaya masuk ke sistem Anda? Setiap kolom formulir, setiap parameter URL, setiap header HTTP, setiap cookie, setiap tubuh permintaan API. Jika itu berasal dari luar memori server Anda, itu tidak tepercaya. Saya telah melihat pengembang yang hati-hati memvalidasi input formulir tetapi sepenuhnya mengabaikan parameter URL, atau membersihkan data POST sementara membiarkan parameter GET terbuka lebar. Penyerang tidak peduli dengan model mental Anda tentang apa yang "seharusnya" divalidasi—mereka menguji semuanya.

Permukaan serangan Anda juga mencakup kerentanan berbasis waktu. Token reset kata sandi yang Anda buat? Jika itu dapat diprediksi atau tidak kedaluwarsa, itu adalah vektor serangan. Identifikasi sesi, kunci API, nama file sementara—apa pun yang mungkin ditebak atau dipaksa oleh penyerang dengan cukup waktu. Saya pernah menemukan sistem di mana token reset kata sandi hanyalah angka berurutan. Seorang penyerang dapat meminta reset untuk akun mereka sendiri, melihat token 45231, lalu mencoba token 45230, 45229, 45228 untuk mereset password pengguna lain.

Validasi Input: Barisan Pertama Pertahanan Anda

Jika saya bisa menato satu prinsip di dahi setiap pengembang, itu akan menjadi ini: jangan pernah percaya input pengguna. Tidak input dari aplikasi seluler Anda. Tidak input dari API "tepercaya" mitra Anda. Bahkan tidak input dari frontend JavaScript Anda sendiri. Segala sesuatu yang melintasi batas kepercayaan harus divalidasi, dibersihkan, dan diperlakukan sebagai berpotensi berbahaya sampai terbukti sebaliknya.

Kerentanan yang paling berbahaya bukanlah yang ditemukan peretas—mereka adalah yang tidak diketahui pengembang ada dalam kode mereka sampai terlambat.

Saya melihat pengembang membuat kesalahan yang sama secara berulang: mereka memvalidasi input di frontend dan berasumsi itu sudah cukup. Berikut adalah kenyataannya—saya bisa melewati validasi frontend Anda dalam waktu sekitar 15 detik menggunakan alat pengembang browser atau perintah curl sederhana. Validasi frontend ditujukan untuk pengalaman pengguna, bukan keamanan. Validasi yang sebenarnya terjadi di server, setiap kali, tanpa pengecualian.

Validasi input yang efektif memiliki tiga komponen: pemeriksaan jenis, validasi format, dan validasi logika bisnis. Pemeriksaan jenis memastikan bahwa kolom yang mengharapkan angka benar-benar menerima angka, bukan string yang berisi upaya injeksi SQL. Validasi format menggunakan daftar yang diizinkan (bukan daftar yang dilarang) untuk memastikan data cocok dengan pola yang diharapkan. Jika Anda mengharapkan alamat email, validasi menggunakan regex email yang tepat. Jika Anda mengharapkan nomor telepon AS, validasi format secara eksplisit.

Validasi logika bisnis adalah tempat kebanyakan pengembang berhenti berpikir. Hanya karena sesuatu secara teknis valid tidak berarti itu masuk akal dalam konteks aplikasi Anda. Saya pernah mereview kode di mana keranjang belanja mengizinkan kuantitas negatif. Pengembang telah memvalidasi bahwa input adalah integer, tetapi tidak pernah memeriksa apakah itu positif. Seorang penyerang dapat "membeli" -100 item dan menerima kredit alih-alih dikenakan biaya. Perbaikannya sangat mudah, tetapi kelalaian tersebut menghabiskan biaya perusahaan sebesar $23.000 sebelum ditemukan.

Berikut adalah pendekatan praktis saya: tetapkan skema ketat untuk setiap input yang diterima aplikasi Anda. Gunakan pustaka validasi seperti Joi untuk Node.js, Pydantic untuk Python, atau validasi bawaan dalam kerangka kerja seperti Laravel atau Django. Pustaka ini memungkinkan Anda untuk mendeklarasikan dengan tepat seperti apa input yang valid, dan mereka menolak segalanya yang lain secara default. Ketika validasi gagal, catat itu. Kegagalan validasi berulang dari alamat IP atau akun pengguna yang sama mungkin menunjukkan ada serangan yang sedang berlangsung.

Satu poin penting lagi: validasi di setiap lapisan. Jika data mengalir dari API Anda ke pekerjaan latar belakang ke database, validasi di setiap langkah. Saya telah melihat serangan yang mengeksploitasi celah antara validasi API dan pemrosesan pekerjaan latar belakang. API memvalidasi input dengan benar, tetapi pekerjaan latar belakang mengasumsikan data aman karena berasal dari database. Seorang penyerang yang dapat menulis langsung ke database (melalui kerentanan terpisah) dapat melewati semua validasi.

Otentikasi dan Otorisasi: Mengetahui Siapa dan Apa

Otentikasi menjawab "siapa Anda?" Otorisasi menjawab "apa yang diizinkan untuk Anda lakukan?" Mencampuradukkan dua konsep ini, atau menerapkannya dengan buruk, menciptakan beberapa kerentanan yang paling mudah dieksploitasi yang saya temui. Saya telah melihat sistem dengan otentikasi yang sangat kuat yang membiarkan pengguna yang terotentikasi mengakses data pengguna lain karena otorisasi adalah pemikiran setelahnya.