Apa itu Cross-Site Scripting (XSS) dan Bahayanya

Dikutip dari laman OWASP, Serangan Cross-Site Scripting (XSS) adalah jenis injeksi, di mana skrip berbahaya disuntikkan ke situs web yang tidak berbahaya dan tepercaya. Serangan XSS terjadi ketika penyerang menggunakan aplikasi web untuk mengirimkan kode berbahaya, umumnya dalam bentuk skrip samping browser, ke pengguna akhir yang berbeda. Cacat yang memungkinkan serangan ini berhasil cukup luas dan terjadi di mana pun aplikasi web menggunakan input dari pengguna dalam output yang dihasilkannya tanpa memvalidasi atau mengkodekannya.

Penyerang dapat menggunakan XSS untuk mengirim skrip berbahaya ke pengguna yang tidak menaruh curiga. Peramban pengguna akhir tidak memiliki cara untuk mengetahui bahwa skrip tidak boleh dipercaya, dan akan mengeksekusi skrip tersebut. Karena menganggap skrip berasal dari sumber tepercaya, skrip berbahaya dapat mengakses cookie, token sesi, atau informasi sensitif lainnya yang disimpan oleh browser dan digunakan dengan situs tersebut. Skrip ini bahkan dapat menulis ulang konten halaman HTML.

Cara Kerja Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) bekerja dengan memanipulasi situs web yang rentan sehingga mengembalikan JavaScript berbahaya kepada pengguna. Saat kode jahat dijalankan di dalam browser korban, penyerang dapat sepenuhnya mengkompromikan interaksi mereka dengan aplikasi.

Penyerang yang mengeksploitasi kerentanan skrip lintas situs biasanya dapat:

1. Meniru atau menyamar sebagai pengguna korban.
2. Melakukan tindakan apa pun yang dapat dilakukan pengguna.
3. Membaca data apa pun yang dapat diakses pengguna.
4. Menangkap kredensial masuk pengguna.
5. Melakukan perusakan virtual situs web.
6. Menyuntikkan fungsionalitas trojan ke dalam situs web.

Jenis-jenis Serangan XSS

1. Reflected cross-site scripting

Reflected XSS adalah jenis skrip lintas situs yang paling sederhana. XSS muncul ketika aplikasi menerima data dalam permintaan HTTP dan menyertakan data tersebut dalam respons langsung dengan cara yang tidak aman.

Berikut adalah contoh sederhana dari kerentanan Reflected XSS :

https://insecure-website.com/status?message=All+is+well.
<p>Status: All is well.</p>

Aplikasi tidak melakukan pemrosesan data lainnya, sehingga penyerang dapat dengan mudah membuat serangan seperti ini:

https://insecure-website.com/status?message=<script>/*+Bad+stuff+here...+*/</script>
<p>Status: <script>/* Bad stuff here... */</script></p>

Jika pengguna mengunjungi URL yang dibuat oleh penyerang, maka skrip penyerang dijalankan di browser pengguna, dalam konteks sesi pengguna dengan aplikasi tersebut. Pada saat itu, skrip dapat melakukan tindakan apa pun, dan mengambil data apa pun, yang aksesnya dimiliki pengguna.

2. Stored cross-site scripting

Stored XSS (juga dikenal sebagai XSS persisten atau urutan kedua) muncul saat aplikasi menerima data dari sumber yang tidak tepercaya dan menyertakan data tersebut dalam respons HTTP selanjutnya dengan cara yang tidak aman.

Data yang dipermasalahkan mungkin dikirimkan ke aplikasi melalui permintaan HTTP; misalnya, komentar di postingan blog, nama panggilan pengguna di ruang obrolan, atau detail kontak di pesanan pelanggan. Dalam kasus lain, data mungkin berasal dari sumber tidak tepercaya lainnya; misalnya, aplikasi email web yang menampilkan pesan yang diterima melalui SMTP, aplikasi pemasaran yang menampilkan postingan media sosial, atau aplikasi pemantauan jaringan yang menampilkan data paket dari lalu lintas jaringan.

Berikut adalah contoh sederhana dari kerentanan Stored XSS. Aplikasi papan pesan memungkinkan pengguna mengirim pesan, yang ditampilkan ke pengguna lain:

<p>Hello, this is my message!</p>

Aplikasi tidak melakukan pemrosesan data lainnya, sehingga penyerang dapat dengan mudah mengirim pesan yang menyerang pengguna lain:

<p><script>/* Bad stuff here... */</script></p>

3. DOM-based cross-site scripting

DOM-based XSS muncul saat aplikasi berisi beberapa JavaScript sisi klien yang memproses data dari sumber yang tidak tepercaya dengan cara yang tidak aman, biasanya dengan menulis data kembali ke DOM.

Dalam contoh berikut, sebuah aplikasi menggunakan beberapa JavaScript untuk membaca nilai dari kolom input dan menulis nilai tersebut ke elemen dalam HTML:

var search = document.getElementById('search').value;
var results = document.getElementById('results');
results.innerHTML = 'You searched for: ' + search;

Jika penyerang dapat mengontrol nilai kolom input, mereka dapat dengan mudah membuat nilai jahat yang menyebabkan skrip mereka sendiri dieksekusi:

You searched for: <img src=1 onerror='/* Bad stuff here... */'>

Dalam kasus umum, kolom masukan akan diisi dari bagian permintaan HTTP, seperti parameter string kueri URL, yang memungkinkan penyerang mengirim serangan menggunakan URL berbahaya, dengan cara yang sama seperti XSS yang direfleksikan.

Cara Menguji Kerentanan XSS

Pertama, untuk menguji serangan XSS, pengujian kotak hitam dapat dilakukan. Artinya, dapat diuji tanpa tinjauan kode. Namun, tinjauan kode selalu merupakan praktik yang disarankan dan juga memberikan hasil yang lebih andal. Dari pengalaman pengujian perangkat lunak saya, saya ingin menambahkan, bahwa jika teknik pengujian kotak hitam yang baik dipilih dan dilakukan secara akurat, maka ini sudah cukup.

Saat memulai pengujian, penguji harus mempertimbangkan bagian situs web mana yang rentan terhadap kemungkinan serangan XSS.

Lebih baik mencantumkannya dalam dokumen pengujian apa pun dan dengan cara ini kami akan yakin, tidak ada yang terlewatkan. Kemudian, penguji harus merencanakan bidang input kode atau skrip apa yang harus diperiksa. Penting untuk diingat, apa arti hasil, bahwa aplikasi tersebut rentan dan menganalisis hasilnya secara menyeluruh.

Saat menguji kemungkinan serangan, penting untuk memeriksa bagaimana responsnya terhadap skrip yang diketik dan apakah skrip tersebut dijalankan atau tidak, dll. Misalnya, penguji dapat mencoba mengetikkan skrip browser seperti:

<script>alert(document.cookie)</script>

Jika skrip ini sedang dieksekusi, maka ada kemungkinan besar XSS itu mungkin. Juga saat menguji secara manual untuk kemungkinan serangan Cross Site Scripting, penting untuk diingat, bahwa tanda kurung yang disandikan juga harus dicoba. Misalnya:

%3cscript%3ealert(document.cookie)%3c/script%3e

Beberapa orang mencoba untuk melindungi website dan sistem dari berbagai serangan dengan mengubah tanda kurung menjadi ganda.

Misalnya , jika kolom input akan diketik dengan tanda kurung “<”, maka akan diubah menjadi double “<<”. Oleh karena itu, penting untuk diingat bahwa pengujian dengan tanda kurung yang disandikan juga harus dijalankan.

Anda tidak boleh lupa untuk menguji URL situs web. Misalnya, kita memiliki permintaan:

http://www.testing.com/test.asp?pageid=2&title=Testing%20Title

Jika serangan ini memungkinkan, maka kode HTML akan menyertakan <h1>Judul Pengujian</h1>. Jika kerentanan ini ada di aplikasi web, teks yang ditunjukkan akan disisipkan dalam tag <h1></h1>.

Mencoba meneruskan beberapa kode melalui permintaan HTTP karena ini juga merupakan metode untuk memeriksa apakah serangan ini mungkin terjadi.

Umumnya, saat menguji kemungkinan serangan XSS, validasi masukan harus diperiksa dan penguji harus sadar saat memeriksa keluaran situs web. Juga jika tinjauan kode sedang dilakukan, penting untuk mengetahui bagaimana input dapat masuk ke dalam output.

Dampak dan Bahaya Serangan XSS

Dampak sebenarnya dari serangan XSS umumnya bergantung pada sifat aplikasi, fungsionalitas dan datanya, serta status pengguna yang disusupi. Misalnya:

1. Dalam aplikasi perangkat brosur, di mana semua pengguna bersifat anonim dan semua informasi bersifat publik, dampaknya seringkali minimal.
2. Dalam aplikasi yang menyimpan data sensitif, seperti transaksi perbankan, email, atau catatan kesehatan, dampaknya biasanya akan serius.
3. Jika pengguna yang disusupi memiliki hak istimewa yang lebih tinggi di dalam aplikasi, maka dampaknya umumnya akan kritis, memungkinkan penyerang mengambil kendali penuh atas aplikasi yang rentan dan membahayakan semua pengguna dan datanya.

Input pengguna yang tidak bersih dapat membuat aplikasi web apa pun berisiko terkena serangan XSS. Bahasa yang paling umum untuk serangan XSS adalah JavaScript, tetapi XSS dapat memengaruhi HTML, Flash, VBScript, CSS, dan bahasa serta kerangka kerja pengembangan web lainnya.

Serangan XSS dapat memiliki konsekuensi yang menghancurkan. Kode yang disuntikkan ke dalam aplikasi yang rentan dapat mengekstraksi data atau menginstal malware di mesin pengguna. Penyerang dapat menyamar sebagai pengguna resmi melalui cookie sesi, memungkinkan mereka melakukan tindakan apa pun yang diizinkan oleh akun pengguna.

XSS juga dapat memengaruhi reputasi bisnis. Penyerang dapat merusak situs web perusahaan dengan mengubah kontennya, sehingga merusak citra perusahaan atau menyebarkan informasi yang salah. Seorang peretas juga dapat mengubah instruksi yang diberikan kepada pengguna yang mengunjungi situs web target, salah mengarahkan perilaku mereka. Skenario ini sangat berbahaya jika targetnya adalah situs web pemerintah atau menyediakan sumber daya vital di saat krisis.

Cara Mencegah Serangan XSS

Mencegah XSS adalah hal yang sepele dalam beberapa kasus, tetapi bisa jauh lebih sulit bergantung pada kerumitan aplikasi dan caranya menangani data yang dapat dikontrol pengguna.

Secara umum, mencegah kerentanan XSS secara efektif kemungkinan melibatkan kombinasi dari langkah-langkah berikut:

1. Filter input pada saat kedatangan.
   Pada titik di mana input pengguna diterima, filter seketat mungkin berdasarkan input yang diharapkan atau valid.
   
   
2. Mengkodekan data pada output.
   Pada titik di mana data yang dapat dikontrol pengguna dikeluarkan dalam respons HTTP, enkode keluaran untuk mencegahnya ditafsirkan sebagai konten aktif. Bergantung pada konteks keluaran, ini mungkin memerlukan penerapan kombinasi penyandian HTML, URL, JavaScript, dan CSS.
   
   
3. Gunakan tajuk respons yang sesuai.
   Untuk mencegah XSS dalam respons HTTP yang tidak dimaksudkan untuk berisi HTML atau JavaScript apa pun, Anda dapat menggunakan header Content-Typeand X-Content-Type-Optionsuntuk memastikan bahwa browser menginterpretasikan respons sesuai keinginan Anda.
   
   
4. Kebijakan Keamanan Konten.
   Sebagai garis pertahanan terakhir, Anda dapat menggunakan Content Security Policy (CSP) untuk mengurangi keparahan kerentanan XSS yang masih terjadi.

Referensi :
1. https://owasp.org/www-community/attacks/xss/
2. https://portswigger.net/web-security/cross-site-scripting
3. https://www.softwaretestinghelp.com/cross-site-scripting-xss-attack-test/
4. https://brightsec.com/blog/xss/