SQL Injection
Deskripsi
SQL Injection (SQLi) terjadi saat aplikasi memasukkan data masukan pengguna secara langsung ke dalam query SQL, sehingga penyerang dapat menyisipkan perintah SQL berbahaya. Misalnya, memasukkan string seperti '; DROP TABLE users; -- dapat menghancurkan tabel jika tidak diantisipasi. Serangan ini serius karena bisa memungkinkan penyerang mengubah atau mencuri data sensitif serta menjalankan perintah administratif di database. Studi Brightsec menjelaskan dampak SQLi: penyerang dapat memodifikasi informasi, mengakses data sensitif, hingga mengeksekusi perintah pada sistem operasi di bawah database.
Kasus Nyata
SQLi telah menjadi penyebab banyak kebocoran data besar. Misalnya, serangan 7-Eleven (2007) mencuri 130 juta nomor kartu kredit. Serangan Team GhostShell (2012) menarget 53 universitas dan membocorkan 36.000 data personal melalui SQLi. Pada 2019, kerentanan SQLi di Fortnite (350 juta pengguna) memungkinkan akses data akun sebelum akhirnya ditutup. Kasus terkini melibatkan aplikasi MOVEit Transfer (2023), di mana peretas memanfaatkan SQLi untuk menanam web shell dan mengekstrak data dalam skala global. Contoh ini menegaskan bahwa SQLi masih menjadi ancaman nyata hingga saat ini.
Deteksi
- Pentest dan Vulnerability Scanning: Gunakan alat pemindai seperti Acunetix atau Burp Suite untuk menguji form input dan parameter URL dengan payload injeksi. Scanner modern dapat menemukan SQLi di fungsi login, pencarian, atau parameter tersembunyi secara otomatis.
- Pengujian Manual (WSTG): Panduan OWASP Web Security Testing (WSTG) merekomendasikan mengirimkan input berbahaya (misalnya OR 1=1, tanda kutip ganda, komentar SQL) dan memantau tanggapan aplikasi. Ciri adanya SQLi meliputi perbedaan pesan kesalahan database atau perubahan hasil query.
- Analisis Log Database: Monitor log query database untuk aktivitas aneh, seperti query yang selalu benar (WHERE '1'='1'), atau frequent error koneksi. Adanya query tak lazim atau error yang terpicu dapat mengindikasikan percobaan SQLi.
- Code Review & SAST: Tinjau kode aplikasi secara statis untuk mencari pola
query = "..."+ input + "..."atau penggunaan fungsi query tanpa parameterisasi. Alat analisis kode (SAST) dapat membantu menemukan konstruksi yang rentan.
Pencegahan dan Perbaikan
- Parameterized Queries (Prepared Statements): Gunakan query parameterized di semua bahasa pemrograman. Ini menjamin database membedakan kode dan data, sehingga input pengguna tidak dapat mengubah struktur query.
- Stored Procedures Aman: Jika menggunakan stored procedures, pastikan parameter input terikat dan statis. Stored procedure yang ditulis dengan benar efektif mencegah SQLi sama seperti prepared statements.
- Least Privilege: Terapkan prinsip hak akses minimal pada akun database. Akun aplikasi cukup diberi hak baca/tulis yang diperlukan (bukan admin atau root), sehingga dampak injeksi dapat dikurangi.
- Validasi Input: Gunakan whitelist untuk input yang tidak dapat diparameterkan, misalnya nama tabel atau kolom.
- ORM dan Abstraksi: Manfaatkan Object-Relational Mapping (ORM) atau framework yang telah teruji keamanan query-nya.
- Pembaruan & Patch: Segera perbarui perangkat lunak (DBMS, library) jika ditemukan kerentanan SQLi.
Cross-Site Scripting (XSS)
Deskripsi
XSS adalah injeksi skrip jahat ke halaman web yang tampak sah. Skrip berbahaya ini biasanya berupa JavaScript yang dijalankan oleh browser korban, karena dianggap berasal dari situs terpercayanya. Akibat XSS bisa berupa pencurian cookie atau token sesi, hingga pemalsuan tampilan halaman untuk menipu pengguna. Penyerang dapat berpura-pura menjadi pengguna yang sah, memuat konten eksternal jahat, atau mencuri data sensitif pengguna. XSS terbagi menjadi reflected, stored, dan DOM-based, tergantung bagaimana skrip disuntikkan dan dijalankan.
Kasus Nyata
Beberapa insiden XSS terkenal: serangan Magecart di situs British Airways (2018) menyisipkan XSS ke pustaka pihak ketiga untuk melakukan skimming kartu kredit pada sekitar 380.000 transaksi. Di Fortnite (2019) ditemukan XSS pada halaman tua yang jika dieksploitasi bisa membajak akun jutaan pemain. Situs eBay pada 2016 sempat memiliki XSS pada parameter URL yang memungkinkan penyerang mengambil alih akun penjual dan memodifikasi daftar barang berharga. Kasus-kasus ini menunjukkan XSS tak hanya teori: kelemahan validasi input dan pustaka pihak ketiga dapat merugikan jutaan pengguna.
Deteksi
- Scanning Otomatis menggunakan pemindai keamanan untuk menyuntikkan payload XSS umum ke berbagai titik input.
- Testing Manual dengan injeksi payload seperti
<script>alert(1)</script>dan memantau eksekusi di browser tester. - Implementasi Content Security Policy (CSP) dengan mode report untuk menangkap pelanggaran XSS.
- Code Review mencari output data ke HTML tanpa encoding dan penggunaan fungsi berisiko seperti
innerHTML. - Pengujian pada platform lab keamanan untuk memastikan semua tipe XSS terdeteksi.
Pencegahan dan Perbaikan
- Validasi dan Encoding Konteksual sebelum menampilkan input pengguna di HTML.
- Framework modern dengan mekanisme templating auto-escaping.
- HttpOnly dan Secure Cookies untuk melindungi token sesi.
- Header CSP ketat untuk membatasi sumber skrip.
- Manajemen script pihak ketiga dengan Subresource Integrity (SRI).
- Audit dan pemindaian rutin untuk mendeteksi kerentanan baru.
Cross-Site Request Forgery (CSRF)
Deskripsi
CSRF adalah serangan yang memaksa pengguna terautentikasi melakukan tindakan yang tidak diinginkan di aplikasi web. Karena browser menyertakan kredensial pada setiap permintaan, aksi berbahaya dapat diproses sebagai permintaan sah. CSRF dapat memindahkan dana, mengubah data, atau melakukan pembelian atas nama korban. Jika korban memiliki hak admin, seluruh aplikasi bisa terkompromi.
Kasus Nyata
Contoh kasus: kerentanan CSRF di Facebook (2019) memungkinkan pengambilalihan akun melalui link jahat; skrip pihak ketiga pada e-commerce global (2025) mengakses token CSRF internal; serangan CSRF pada uTorrent (2008) menyebarkan malware melalui GET request.
Deteksi
- Vulnerability Scanning memeriksa formulir tanpa token CSRF.
- Pengujian Manual dengan permintaan tanpa atau token salah.
- Analisis Kode memastikan token CSRF diperiksa pada endpoint.
- Monitoring header Referer dan Origin.
Pencegahan dan Perbaikan
- Synchronizer Token Pattern dengan token unik per form yang diverifikasi backend.
- Double-Submit Cookie untuk API.
- SameSite Cookie pada sesi.
- Header kustom pada permintaan API.
- Validasi header Referer/Origin domain yang sama.
- Hindari GET untuk aksi sensitif.
- Gunakan proteksi CSRF bawaan framework.
- Defense-in-Depth: 2FA, batas waktu token, CAPTCHA.