Serangan siber terhadap aplikasi web terus meningkat setiap tahun. Laporan Verizon DBIR 2021 menunjukkan bahwa serangan pada aplikasi web menjadi salah satu vektor paling umum dalam kebocoran data. Bahkan Microsoft mencatat lonjakan serangan lapisan aplikasi hingga 4× lipat pada paruh kedua 2024. Kondisi ini menggarisbawahi pentingnya pemahaman terhadap kerentanan aplikasi web. Artikel ini mengungkap tujuh kerentanan populer yang kerap dieksploitasi peretas, agar pengembang dan pemilik bisnis digital dapat lebih siap mencegahnya.

SQL Injection (SQLi) – Celah Abadi yang Masih Relevan

Apa itu SQLi? SQL Injection terjadi ketika input pengguna tidak tervalidasi atau tidak disanitasi dengan benar, kemudian dimasukkan ke dalam perintah SQL dinamis. Sebagai hasilnya, penyerang dapat memanipulasi query database. Misalnya, memasukkan payload seperti idontknow' OR 1=1;-- dapat merubah logika login sehingga bisa login tanpa kredensial valid.
Dampak nyata: SQLi bisa mencuri seluruh data sensitif dalam basis data, mengubah konten, atau melewati mekanisme autentikasi. Studi kasus “ResumeLooters” (Nov–Des 2023) menunjukkan hal ini: kelompok ini memanfaatkan SQLi (dan XSS) untuk mengekstraksi data dari 65 situs rekrutmen/ritel, mencuri data pribadi lebih dari 2 juta pencari kerja.
Pencegahan dan deteksi: Pencegahan utama adalah memisahkan data dari perintah. Gunakan prepared statement atau ORM yang mendukung parameterisasi agar masukan pengguna tidak menjadi bagian query langsung. Validasi input secara ketat (pilihan white-list) dan hindari konstruk query dinamis dengan penggabungan string. Praktik terbaik juga meliputi pemeriksaan kode (source code review) dan uji penetrasi otomatis. Tools SAST/DAST dapat membantu menemukan injeksi sejak fase pengembangan.

Contoh mitigasi: Gunakan API akses data yang aman (parameterized queries). Validasi input pada server menggunakan pola putih (only allow expected characters). Hindari menampilkan pesan error SQL atau hasil query mentah ke pengguna.

Cross-Site Scripting (XSS) – Serangan yang Mengintai Input Tak Aman

Definisi XSS: Menurut OWASP, XSS adalah jenis injeksi di mana skrip berbahaya disisipkan ke situs web yang seharusnya terpercaya. Ini terjadi ketika aplikasi mengambil input pengguna yang tak aman dan menampilkannya kembali ke pengguna lain tanpa penyaringan atau enkoding yang tepat.
Dampak: Jika kode jahat dijalankan di browser korban, pelaku bisa mencuri cookie, token sesi, atau data sensitif lainnya dari pengguna. Skrip terinfeksi juga bisa memanipulasi tampilan halaman web korban.
Jenis XSS: XSS umumnya terbagi menjadi Stored (tersimpan di server), Reflected (terkirim kembali melalui respons), dan DOM-based (manipulasi dokumen di browser). Ketiga tipe ini sering terdeteksi di aplikasi modern yang mengabaikan sanitasi input.
Contoh kasus: Kampanye “ResumeLooters” juga memanfaatkan XSS bersama SQLi untuk menyusupi 65 situs dan mencuri data 2 juta pengguna. Kasus lain, pada 2019 terjadi pembobolan jutaan akun Fortnite akibat XSS di sebuah halaman situs lama yang sudah tidak terpakai.
Mitigasi: Selalu enkode atau hilangkan karakter berbahaya dari masukan pengguna sebelum menampilkannya. Terapkan Content Security Policy (CSP) dan header keamanan seperti X-XSS-Protection. Gunakan metode output encoding kontekstual (HTML escape) untuk menghindari eksekusi skrip.

Contoh mitigasi: Validasi dan enkode semua input pengguna yang ditampilkan di halaman web. Gunakan framework atau library yang otomatis mencegah XSS (misalnya React, Vue dengan binding yang aman). Terapkan CSP untuk membatasi sumber skrip.

Broken Authentication – Kunci Lemah yang Mudah Dibobol

Definisi Broken Auth: Merupakan celah pada proses autentikasi atau manajemen sesi. Jika implementasinya buruk, penyerang bisa mengambil alih akun pengguna. Contoh: ID sesi (cookie/token) yang tidak di-invalidasi saat logout atau bisa diprediksi, atau penggunaan password lemah/default tanpa MFA.
Akibat: Akun pengguna dapat diretas sepenuhnya, data pribadi bocor, hingga eskalasi hak akses (privilege escalation). Penyerang bisa menggunakan mekanisme credential stuffing atau brute force untuk menyerang akun. Brightsec menyorot bahwa eksposur sesi di URL, timeout yang tidak diatur, atau hashing password yang lemah adalah celah umum Broken Auth.
Faktor penyebab: Penggunaan password default/umum, tidak adanya proteksi MFA, proses lupa sandi yang mudah ditebak. Jika token atau cookie dikirim tanpa enkripsi (HTTPS), or reuse sesi yang sama menyebabkan autentikasi pecah.
Tips pengamanan: Terapkan multi-factor authentication untuk menghambat credential stuffing dan password reuse. Jangan gunakan kredensial bawaan (seperti admin/admin). Terapkan batasan percobaan login dan lockout, serta log semua kejadian gagal autentikasi untuk deteksi dini. Pastikan sesi di-server dan token di-browser segera dihapus atau dibuat ulang setelah logout.

Contoh mitigasi: Pakai hashing sandi yang kuat (misal bcrypt/Argon2 dengan salt) dan simpan tidak dalam bentuk teks. Tetapkan kebijakan sesi: timeout otomatis setelah inaktivitas, dan hapus sesi dari server saat logout. Gunakan layanan keamanan identitas terpercaya dan perbarui terus algoritma kriptografi.

Security Misconfiguration – Kesalahan Kecil, Risiko Besar

Penjelasan: Security Misconfiguration terjadi bila setup sistem tidak dikunci dengan benar. Contoh umum menurut OWASP: fitur tidak perlu sengaja dibiarkan aktif, hak akses cloud terlalu longgar, akun/default password tidak diubah, atau pesan error yang menampilkan detail teknis. Misalnya, mengaktifkan directory listing atau panel admin terbuka dapat dengan mudah dimanfaatkan.
Penyebab: Keterburu-buruan tim DevOps sering kali melewatkan hardening. Fokus cepat rilis membuat konfigurasi keamanan terabaikan. Selain itu, banyaknya komponen dan layanan juga mempermudah terjadinya kesalahan setup.
Contoh kasus: Sebuah bucket AWS S3 yang tidak dikonfigurasi dengan benar pernah mengekspos 3 TB data bandara (1,5 juta file) secara publik, termasuk foto pekerja dan informasi sensitif lainnya. Kasus ini menunjukkan betapa kecilnya kesalahan config bisa berakibat bencana data leak.
Mitigasi: Terapkan konfigurasi standar yang aman (disable fitur debugging, sample app, dsb.). Ganti semua kredensial bawaan dengan yang kuat. Nonaktifkan direktori listing dan sembunyikan endpoint internal (misal /admin). Selalu tampilkan pesan error generik tanpa informasi server.

• Tools pemindaian: Gunakan scanner otomatis (DAST/SAST) yang tersedia. OWASP mencantumkan beragam tools yang dapat memeriksa XSS, SQLi, dan konfigurasi server yang tidak aman. Contoh: Nessus, OWASP ZAP, Nikto, atau tools integrasi CI/CD seperti Snyk, Acunetix.
• Checklist konfigurasi aman: Terapkan HTTPS dengan HSTS; aktifkan header keamanan (Content Security Policy, X-Frame-Options, X-Content-Type-Options, dll.); sesuaikan izin hak akses hanya yang diperlukan; dan rutin update patch server/framework.

Sensitive Data Exposure – Bocornya Informasi Berharga

Apa itu? Sensitive Data Exposure terjadi ketika aplikasi secara tidak sengaja membocorkan informasi rahasia (PII, data finansial, kredensial) ke pihak tak berwenang. Parasoft mendefinisikan bahwa ini bisa terjadi karena perlindungan data yang lemah, enkripsi tidak digunakan, atau kontrol akses yang buruk.

Contoh data sensitif: Nomor KTP/SSN, data kartu kredit, rekam medis, serta kredensial login. Semua ini harusnya dilindungi ketat oleh kebijakan keamanan dan regulasi (misal GDPR, PCI DSS). OWASP 2017 menyoroti bahwa PII seperti catatan kesehatan, data pribadi, dan kartu kredit memerlukan proteksi khusus.

Kesalahan umum: Menyimpan data penting dalam teks jelas (cleartext) tanpa enkripsi, mengirim data melalui koneksi tidak aman (HTTP), atau mencatat informasi sensitif di log tanpa filter. Contoh fatal: Equifax 2017, di mana bocoran data 147 juta orang AS (termasuk SSN dan alamat) terjadi karena celah keamanan.

Risiko: Bocornya data pribadi menimbulkan kerugian finansial dan reputasi. Perusahaan bisa dikenai sanksi hukum dan denda besar (GDPR, undang-undang privasi).

Langkah preventif: Enkripsi data penting baik saat tersimpan (at rest) maupun saat ditransmisikan (in transit). Misalnya, gunakan TLS untuk semua lalu lintas web dan enkripsi basis data (AES). Terapkan tokenisasi atau pembatasan akses (hanya aplikasi tertentu yang bisa mendekripsi data). Batasi penyimpanan data sensitif – jika tidak perlu disimpan, hapus atau anonymize segera.

Contoh mitigasi: Gunakan algoritma enkripsi kuat (AES-256) dan rotasi kunci secara berkala. Pastikan komunikasi menggunakan HTTPS dengan sertifikat valid. Simpan password menggunakan hashing salted (bcrypt/Argon2). Nonaktifkan cache respons yang memuat data sensitif (header HSTS, no-cache).

Broken Access Control – Saat Pengguna Bisa Akses Lebih dari Haknya

Penjelasan: Broken Access Control terjadi ketika kontrol otorisasi gagal mencegah pengguna melakukan hal di luar haknya. Artinya, seorang pengguna biasa bisa mengakses data atau fungsi seharusnya hanya untuk admin.
Contoh serangan: Sering terjadi IDOR (Insecure Direct Object Reference). Misalnya, penyerang dapat mengubah parameter userId dalam URL dan melihat data pengguna lain. OWASP menyebut bypass kontrol akses dengan memodifikasi URL/parameter sebagai kelemahan umum, termasuk memberikan ID akun milik orang lain dalam permintaan. Ada juga eskalasi hak (misal pengguna reguler bisa menggunakan API admin jika token tidak dicek).
Studi kasus: Misalkan ada endpoint GET /account?id=123. Jika sistem tidak memverifikasi kepemilikan, pengguna bisa mengganti 123 menjadi ID lain dan melihat data orang lain – inilah contoh Broken Access Control.
Mitigasi: Terapkan prinsip deny-by-default: kecuali sumber daya publik, semua permintaan harus diperiksa hak aksesnya di server. Gunakan mekanisme kontrol akses yang konsisten (berdasarkan peran dan kepemilikan data). CORS harus dikonfigurasi hanya untuk origin tepercaya. Selalu validasi sisi server (bukan hanya di front-end) untuk memastikan pengguna hanya bisa mengakses data atau fungsi sesuai izinnya.

• Contoh mitigasi: Buat token sesi yang terikat pengguna tertentu dan periksa pada setiap permintaan. Gunakan parameter internal yang tidak mudah ditebak (misal UUID). Hindari meletakkan file .git, backup, atau katalog list yang mengandung data sensitif di folder publik.

Insecure Deserialization – Serangan Tersembunyi Lewat Objek

Penjelasan teknis: Deserialisasi adalah proses mengembalikan objek dari data tersimpan. Jika aplikasi mendeserialisasi data yang tidak tepercaya (misal file atau input pengguna), penyerang bisa memodifikasi data tersebut sehingga mengubah logika aplikasi atau mengeksekusi kode berbahaya. OWASP menjelaskan bahwa Insecure Deserialization muncul saat data ter-serialisasi yang tidak aman digunakan untuk membajak proses deserialisasi dan menjalankan kode asing.

Eksploitasi: Umumnya berujung pada Remote Code Execution (RCE). Misalnya, penyerang dapat mengganti file serialized (seperti cookies.ser) dengan objek ter-serialisasi jahat, yang saat dibaca aplikasi bisa menjalankan perintah OS secara otomatis. Selain itu dapat memicu DoS (memuat objek besar kompleks) atau elevasi hak karena kelas yang dideserialisasi memiliki hak tinggi.

Tantangan deteksi: Celah ini susah ditemukan karena melibatkan proses parsing objek kompleks. Biasanya baru terungkap saat pen-test mendalam. Pemeriksaan statis pun belum tentu mengcover skenario ini.
Cara hardening: Jangan mendeserialisasi objek dari sumber tidak terpercaya. Jika terpaksa, lakukan validasi integritas data (misal tanda tangan digital) agar memverifikasi objek asli. Batasi tipe kelas yang boleh dideserialisasi (whitelisting). Jalankan deserialisasi di sandbox terisolasi untuk mencegah kode berbahaya meluas. Pilih format yang lebih aman seperti JSON daripada format binary Java/Php/NET bawaan.

• Contoh mitigasi: Pastikan data serialized di-sign dengan kunci rahasia; gunakan library ObjectInputFilter (Java 9+) atau setelan deserialisasi ketat. Hindari menggunakan eval atau eval-like pada data terdeserialisasi.

Mengapa Kerentanan Ini Sering Terulang?

Banyak perusahaan abai pada keamanan sejak awal. Survei industri menunjukkan 86% pengembang tidak menganggap keamanan aplikasi sebagai prioritas utama, bahkan 67% sadar tapi tetap merilis kode rentan demi tenggat waktu. Tekanan deadline (24% responden) dan minimnya pelatihan (20%) disebut sebagai penghambat utama penerapan secure coding. Selain itu, minimnya pengujian keamanan rutin (audit atau pentest) membuat kerentanan lama tidak terdeteksi. Kondisi ini diperparah oleh budaya “kejar tayang” dalam proyek digital, di mana prosedur QA keamanan sering diabaikan.

Langkah Praktis untuk Mendeteksi dan Mencegah

1. Penetration Testing & Vulnerability Assessment berkala: Lakukan pengujian lubang keamanan secara rutin (minimal setahun 1–2 kali, atau saat ada perubahan besar). Pentest membantu menemukan celah sebelum disalahgunakan.
2. Gunakan OWASP Top 10 sebagai acuan: OWASP menyatakan Top 10 adalah dokumen standar untuk risiko aplikasi web terbesar, dan “mungkin langkah pertama paling efektif” untuk mengubah kultur pengembangan menjadi lebih aman. Pastikan tim dev memahami dan mengevaluasi kode terhadap daftar kerentanan ini.
3. Pelatihan Keamanan untuk Tim Dev: Berikan kursus atau sertifikasi secure coding kepada pengembang. Semakin tinggi literasi keamanan tim, semakin cepat celah dapat diantisipasi.
4. Kombinasi tool pemindaian otomatis dan manual: Gunakan tools SAST (scanning kode sumber) dan DAST (scanning aplikasi aktif) dalam pipeline CI/CD. Contohnya, OWASP mencantumkan berbagai pemindai yang dapat mendeteksi XSS, SQLi, hingga konfigurasi server yang salah. Lengkapi dengan pengujian manual (code review, pentest) agar celah kompleks dapat terdeteksi.
5. Proses Secure SDLC: Terapkan standar keamanan dalam setiap tahap pengembangan — mulai threat modeling, code review berfokus keamanan, hingga regression test. Terapkan patch dan update komponen pihak ketiga secara teratur.

Kesimpulan

Ketujuh kerentanan aplikasi web yang telah dibahas merupakan ancaman nyata yang kerap dimanfaatkan oleh peretas setiap hari. Mulai dari SQL Injection, XSS, hingga Insecure Deserialization, masing-masing memiliki potensi merusak yang besar apabila tidak ditangani secara tepat. Data dan studi kasus yang disajikan menunjukkan bahwa kelalaian terhadap aspek keamanan bukanlah pilihan yang bisa diambil oleh organisasi digital manapun di era saat ini.

Masalah keamanan bukan semata tanggung jawab tim TI, melainkan bagian dari strategi bisnis secara keseluruhan. Kerentanan yang tampaknya kecil bisa berdampak besar terhadap kepercayaan pelanggan, integritas data, dan keberlanjutan bisnis. Oleh karena itu, penting bagi setiap pemilik bisnis, pengembang, dan pengambil keputusan TI untuk menjadikan keamanan sebagai prioritas sejak tahap perencanaan dan pengembangan aplikasi.

Memahami dan mengenali kerentanan hanyalah langkah awal. Tindakan nyata seperti melakukan pengujian keamanan secara berkala, membekali tim dengan pelatihan yang relevan, serta menjalin kemitraan dengan pihak berpengalaman adalah fondasi penting dalam membangun sistem yang tangguh.

Jika Anda ingin mengidentifikasi dan menutup kerentanan sebelum diserang, kini saatnya untuk mengambil langkah konkret. Jangan tunggu hingga insiden terjadi baru bertindak.

🛡️ Hubungi tim Fourtrezz untuk kerja sama pengujian keamanan aplikasi Anda: 👉 fourtrezz.co.id | +62 857-7771-7243 | [email protected]