Menguji Pembuatan Skrip Lintas Situs

Cross-site Scripting (XSS) terjadi setiap kali aplikasi mengambil data yang tidak tepercaya dan mengirimkannya ke klien (browser) tanpa validasi. Hal ini memungkinkan penyerang untuk mengeksekusi skrip berbahaya di browser korban yang dapat mengakibatkan pembajakan sesi pengguna, merusak situs web, atau mengarahkan pengguna ke situs jahat.

Mari kita pahami Agen Ancaman, Vektor Penyerang, Kelemahan Keamanan, Dampak Teknis, dan Dampak Bisnis dari kelemahan ini dengan bantuan diagram sederhana.

Jenis XSS

  • Stored XSS - Stored XSS juga dikenal sebagai persistent XSS terjadi ketika input pengguna disimpan di server target seperti database / forum pesan / kolom komentar, dll. Kemudian korban dapat mengambil data yang disimpan dari aplikasi web.

  • Reflected XSS - XSS yang direfleksikan juga dikenal sebagai XSS non-persisten terjadi ketika input pengguna segera dikembalikan oleh aplikasi web dalam pesan kesalahan / hasil pencarian atau input yang diberikan oleh pengguna sebagai bagian dari permintaan dan tanpa menyimpan data yang diberikan pengguna secara permanen.

  • DOM Based XSS - DOM Berbasis XSS adalah bentuk XSS jika sumber datanya ada di DOM, sink juga ada di DOM, dan aliran data tidak pernah meninggalkan browser.

Contoh

Aplikasi menggunakan data tidak tepercaya dalam konstruksi tanpa validasi. Karakter khusus harus di-escape.

http://www.webpage.org/task/Rule1?query=try

Penyerang mengubah parameter kueri di browsernya menjadi -

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

Tangan di atas

Step 1- Masuk ke Webgoat dan arahkan ke Bagian pembuatan skrip lintas situs (XSS). Mari kita jalankan serangan Stored Cross-site Scripting (XSS). Di bawah ini adalah snapshot dari skenario tersebut.

Step 2- Sesuai skenario, mari kita login sebagai Tom dengan kata sandi 'tom' seperti yang disebutkan dalam skenario itu sendiri. Klik 'lihat profil' dan masuk ke mode edit. Karena tom adalah penyerang, mari kita masukkan skrip Java ke dalam kotak edit tersebut.

<script> 
   alert("HACKED")
</script>

Step 3 - Segera setelah pembaruan selesai, tom menerima kotak peringatan dengan pesan "diretas" yang berarti aplikasi tersebut rentan.

Step 4 - Sekarang sesuai skenario, kita perlu login sebagai jerry (HR) dan memeriksa apakah jerry dipengaruhi oleh skrip yang diinjeksi.

Step 5 - Setelah masuk sebagai Jerry, pilih 'Tom' dan klik 'lihat profil' seperti yang ditunjukkan di bawah ini.

Saat melihat profil tom dari akun Jerry, dia bisa mendapatkan kotak pesan yang sama.

Step 6 - Kotak pesan ini hanyalah sebuah contoh, tetapi penyerang sebenarnya dapat melakukan lebih dari sekedar menampilkan kotak pesan.

Mekanisme Pencegahan

  • Pengembang harus memastikan bahwa mereka keluar dari semua data yang tidak tepercaya berdasarkan konteks HTML seperti badan, atribut, JavaScript, CSS, atau URL tempat data ditempatkan.

  • Untuk aplikasi yang membutuhkan karakter khusus sebagai masukan, harus ada mekanisme validasi yang kuat sebelum menerimanya sebagai masukan yang valid.