Apa itu Cross Site Scripting (XSS) ?

XSS (Cross-Site Scripting) adalah teknik di mana penyerang mencoba “menyisipkan” skrip atau instruksi ke dalam halaman web yang dilihat orang lain. Bayangkan seseorang menulis pesan di papan pengumuman—jika papan itu tidak memeriksa isi pesan, orang jahat bisa menulis instruksi yang membuat pembaca melakukan hal yang tidak mereka sadar. Di artikel ini kita akan melihat tiga jenis XSS yang umum dan bagaimana setiap tingkat pengamanan di DVWA memengaruhi risiko tersebut.

Tipe Tipe Cross Site Scripting

Reflected XSS

Reflected XSS muncul ketika sebuah situs menampilkan kembali (memantulkan) input pengguna ke halaman tanpa membersihkannya terlebih dahulu. Pelaku biasanya meletakkan muatan berbahaya ke dalam sebuah tautan—ketika korban mengunjungi tautan tersebut, laman menampilkan muatan itu dan efeknya berlangsung pada browser korban.

Stored XSS

Stored XSS terjadi ketika masukan berbahaya disimpan di server—misalnya di kolom komentar atau profil—dan kemudian ditampilkan kepada setiap pengunjung halaman tersebut. Karena muatan tersimpan, satu entri jahat bisa memengaruhi banyak pengguna. Browser pengunjung akan mengeksekusi masukan berbahaya tanpa disadari oleh pengguna tersebut.

DOM XSS

DOM XSS terjadi ketika skrip di halaman mengubah konten berdasarkan data lokal (mis. bagian dari URL atau nilai form) tanpa memeriksanya. Akibatnya, halaman bisa menjadi berbahaya hanya di sisi browser pengguna, sementara server terlihat “bersih”.

DVWA dan hubungannya dengan XSS

DVWA (Damn Vulnerable Web Application) adalah sebuah aplikasi web yang sengaja dibuat dengan banyak celah keamanan. Tujuannya bukan untuk dipakai sehari-hari, melainkan sebagai “laboratorium” belajar keamanan aplikasi web. Dengan DVWA, pengguna dapat berlatih memahami bagaimana serangan bekerja dan bagaimana cara pertahanannya, tanpa membahayakan situs asli di internet.

Salah satu topik penting yang ditawarkan DVWA adalah Cross-Site Scripting (XSS). DVWA menyediakan tiga skenario XSS—Reflected, Stored, dan DOM—masing-masing dibagi lagi ke dalam empat tingkat kesulitan: Low, Medium, High, dan Impossible.

• Low: input pengguna diterima begitu saja tanpa pemeriksaan, sehingga serangan sangat mudah dilakukan.
• Medium: ada upaya penyaringan sederhana, tapi belum sempurna.
• High: penyaringan lebih ketat dan sebagian input diubah agar lebih aman.
• Impossible: input benar-benar divalidasi dan diubah, sehingga serangan XSS tidak bisa dilakukan.

Dampak XSS

XSS bisa membuat penyerang mencuri akses sementara ke akun Anda. Misalnya, ketika Anda membuka sebuah halaman yang terinfeksi, skrip jahat bisa membaca cookie sesi atau token masuk dan mengirimkannya ke penyerang. Akibatnya pelaku bisa “masuk sebagai Anda” untuk sementara — melihat pesan pribadi, mengubah pengaturan, atau mengirim pesan palsu atas nama Anda tanpa harus mengetahui kata sandi.

XSS sering dipakai untuk phishing yang tampak sangat meyakinkan. Alih-alih kirim email palsu, penyerang menanam konten di halaman asli yang Anda percaya: pesan palsu, form login palsu, atau pop-up yang meminta informasi sensitif. Karena tampilannya berada di situs yang sah, korban lebih mudah tertipu memasukkan data pribadi atau finansial.

Singkatnya: XSS bukan hanya masalah “teknis” yang tampak kecil — dampaknya nyata dan beragam: dari pembajakan akun dan penipuan yang meyakinkan, sampai penyebaran malware dan kerusakan reputasi secara luas. Mengetahui tanda-tandanya dan menerapkan langkah pencegahan sederhana dapat menyelamatkan pengguna dan organisasi dari konsekuensi yang serius.

Simulasi XSS dengan DVWA

XSS stored level low

Secara default kita bisa login sebagai user dengan password yang sama dengan usernamenya. Tapi kalian juga bisa login sebagai admin dengan password yang sama juga dengan usernamenya.

setelah login masuk kedalam XSS stored. Kalian bebas memasukkan nama apa saja. Lalu kita masukkan function script pada kolom komentar, disini saya menggunakan alert untuk menampilkan notifikasi hi dummy. Alasan saya menggunakan function tersebut adalah demi keamanan, supaya tidak ada orang iseng yang menyalahgunakan jika saya memasukkan function yang berbahaya.

setelah itu notifikasi yang berisikan pesan yang kita masukkan sebelumnya muncul. Ini artinya bahwa function yang kita masukkan sebelumnya berjalan dibelakang layar, yang bahkan pengunjung website tersebut tidak akan menyadari bahwa ada malware berbahaya didalamnya.

Bisa dilihat kalau function script yang kita masukkan sebelumnya tersimpan kedalam source code website tersebut bahkan tidak ada perubahan apapun dari function yang kita masukkan sebelumnya. Artinya bahwa pengunjung lain akan mengalami kejadian yang sama dengan yang kita alami pada tahap sebelumnya. Ini sangat berbahaya karena akan ada banyak pengunjung yang mengalami peretasan yang tidak mereka sadari.

Stored XSS memungkinkan skrip berbahaya tersimpan di server dan dijalankan di browser pengunjung. Jika kita lihat pada source code dari sisi server, input dari user tidak divalidasi yang artinya masukkan apapun akan disimpan dan dieksekusi oleh pengunjung yang datang ke website tersebut.

XSS stored level medium

Untuk level medium sudah diberikan filterisasi pada kolom message, singkatnya function seperti addslashes, htmlspecialcahrs, strip_tags akan mengubah input apapun pada kolom message menjadi teks biasa yang tidak akan dieksekusi server.

Alasan kenapa variasi payload dengan huruf besar-kecil masih bisa lolos adalah karena fungsi str_replace hanya menghapus teks <script> dalam bentuk huruf kecil semua. Dengan kata lain, filter ini sangat lemah karena tidak mempertimbangkan variasi lain seperti <ScRiPt> atau penggunaan atribut HTML lain yang bisa tetap mengeksekusi kode berbahaya.

Sebelum kita mensimulasikan serangan pada website tersebut kita harus memodifikasi sedikit tampilannya terlebih dahulu, karena kolom Name membatasi jumlah karakter didalamnya. Kita tinggal inspect lalu memofdifikasi maxlength=10 menjadi angka yang cukup untuk input kita nantinya.

disini saya memasukkan kode yang sama seperti sebelumnya namun ingat server menghapus kode <script> jadi kita harus sedikit memodifikasinya. Kita masukkan kode kedalam kolom name yang vulnerable seperti yang sudah dijelaskan sebelumnya dan isi kolom message dengan apapun.

Bisa kita lihat bahwa skrip yang kita masukkan kedalam kolom name tersimpan pada server sama seperti sebelumnya.

XSS stored level high

Meski level ‘high’ melakukan beberapa pembersihan input, pendekatannya bercampur: ada perlindungan untuk database dan ada encoding untuk tampilan, tapi keduanya dilakukan tanpa aturan yang konsisten. Karena pembersihan dilakukan pada saat penyimpanan dan tidak selalu sesuai konteks tampilan (HTML vs atribut vs JavaScript), ada celah yang masih bisa dimanfaatkan.

Server menetralkan skrip yang Anda masukkan dengan mengubah tanda <, > dan tanda kutip menjadi kode aman (mis. <, >, "), sehingga browser menampilkan teks skrip tersebut sebagai tulisan biasa dan tidak menjalankannya.

Proses Mitigasi XSS

Untuk mencegah bahaya yang muncul dari stored XSS yaitu skrip berbahaya yang disimpan di server lalu dijalankan di browser pengunjung pengelola situs harus memastikan bahwa semua teks yang dikirim pengguna tidak pernah diperlakukan sebagai kode yang boleh dijalankan.

Jangan pernah percaya input dari pengguna: semua data yang masuk harus divalidasi dan disaring di sisi server (bukan hanya di browser). Gunakan allowlist untuk menerima hanya format dan panjang yang benar (mis. angka, email, atau teks tanpa tag HTML), batasi ukuran input, dan gunakan pustaka sanitasi yang teruji untuk membersihkan konten yang memang perlu menampilkan HTML. Validasi sisi server mencegah skrip jahat tersimpan di basis data meskipun ada celah pada sisi klien.

Selalu lakukan output encoding sesuai konteks sebelum menampilkan data ke browser — artinya karakter berbahaya diubah menjadi bentuk yang aman sehingga tidak dijalankan sebagai kode. Manfaatkan mekanisme template atau framework yang otomatis melakukan escaping, dan terapkan header keamanan seperti Content-Security-Policy untuk membatasi sumber skrip yang boleh dijalankan. Selain itu, beri proteksi pada cookie sesi dengan atribut Secure dan HttpOnly serta SameSite agar skrip di halaman tidak mudah mencuri atau mengirimkan informasi sesi.

Keamanan XSS paling efektif bila menerapkan beberapa lapis pertahanan: update dan patch dependensi secara rutin, lakukan code review dan pengujian keamanan (termasuk scanning dan pengujian aplikasi), serta aktifkan pemantauan dan logging untuk mendeteksi aktivitas mencurigakan. Untuk lapisan tambahan pada level infrastruktur, pertimbangkan Web Application Firewall (WAF) dan pendidikan developer tentang pola serangan XSS — kombinasi kebijakan, praktik pengkodean aman, dan monitoring akan jauh lebih andal daripada bergantung pada satu mekanisme saja.

Penutup

Pada akhirnya, serangan XSS mungkin terlihat sederhana, namun dampaknya bisa sangat serius bagi pengguna maupun pemilik aplikasi. Celah sekecil apa pun pada input pengguna dapat menjadi pintu masuk bagi peretas untuk mencuri data, mengambil alih akun, atau merusak reputasi sebuah layanan. Karena itu, memahami bagaimana XSS bekerja dan menerapkan mitigasi yang tepat bukanlah pilihan, melainkan kebutuhan. Dengan kombinasi validasi input, encoding output, serta kesadaran keamanan yang berkelanjutan, kita dapat meminimalisir risiko dan menjaga aplikasi tetap aman digunakan oleh semua orang.