Photo by Catherine Heath on Unsplash
Pendahuluan
Dalam dunia pengujian keamanan aplikasi web, mencari celah XSS (Cross-Site Scripting) secara manual bisa menjadi proses yang memakan waktu dan sangat repetitif. Oleh karena itu, penggunaan alat bantu otomatis seperti Dursgo, Dalfox, dan Nuclei menjadi sangat penting untuk meningkatkan efisiensi dan efektivitas dalam menemukan kerentanan ini.
Namun, sebelum membahas penggunaan alat-alat tersebut, mari kita lihat bagaimana proses manual bekerja dan mengapa otomasi sangat membantu.
Inisiasi Target
Untuk memulai proses pencarian celah, saya menggunakan teknik Google Dork untuk menemukan situs-situs yang memiliki program bug bounty aktif. Salah satu hasil pencarian mengarahkan saya pada dokumen resmi dari situs redacted.com, yang menyatakan secara eksplisit bahwa mereka menerima laporan kerentanan melalui email di support@redacted.com.
Situs tersebut kemudian saya jadikan sebagai target eksplorasi untuk mendeteksi celah keamanan.
Fokus Pengujian: Cross-Site Scripting (XSS)
Fokus utama dari eksplorasi ini adalah menemukan kerentanan XSS. Saya menggunakan dua pendekatan:
Pendekatan Manual (Oneliner/Fuzzing)
Mencari dan mengidentifikasi parameter dengan alat seperti Arjun, kemudian melakukan fuzzing secara manual.Pendekatan Otomatis
Menggunakan alat bantu seperti Dalfox, Nuclei, dan Dursgo. Pada eksplorasi ini, saya menggunakan Dursgo secara lebih mendalam, karena Dalfox dan Nuclei mungkin sudah cukup dikenal.
About XSS
Tapi sebelum itu, izinkan saya menjelaskan apa itu xss dan jenis-jenis nya, XSS (Cross-Site Scripting) adalah celah keamanan pada aplikasi web yang memungkinkan penyerang menyisipkan malicious JavaScript melalui form input atau URL secara langsung. Kerentanan ini terjadi karena input dan output tidak difilter dengan benar, sehingga kode berbahaya dijalankan oleh browser seolah-olah itu skrip yang sah.
Terdapat tiga jenis utama XSS, yaitu Stored XSS, Reflected XSS, dan DOM-based XSS. Lalu, mengapa Self-XSS tidak disebutkan? Menurut saya, Self-XSS bukanlah jenis XSS yang berdiri sendiri, melainkan merupakan turunan dari kondisi yang bisa terjadi pada ketiga jenis XSS tersebut.
Sebagai contoh, Stored XSS bisa bersifat ‘self’ tergantung kompleksitas target, terutama saat diperlukan chaining dengan serangan lain seperti CSRF untuk menyimpan payload di sisi korban. Reflected XSS pun pada dasarnya bisa bersifat ‘self’ jika hanya dimanfaatkan oleh penyerang terhadap dirinya sendiri tanpa merugikan pengguna lain. Namun karena payload-nya terdapat di URL dan bisa dikirim ke pengguna lain melalui berbagai mekanisme, maka Reflected XSS tetap dikategorikan sebagai serangan terhadap user. Oleh karena itu, dalam perhitungan CVSS biasanya diberi nilai UI:Required (user interaction required).
Intinya, Self-XSS lebih menggambarkan konteks eksploitasi, bukan termasuk dalam klasifikasi utama jenis XSS.
Type XSS
Stored XSS (Stored Cross Site Scripting) adalah jenis serangan XSS di mana payload berbahaya yang dimasukkan oleh attacker disimpan secara permanen di server (database). Payload ini kemudian ditampilkan kembali kepada pengguna lain melalui halaman web yang rentan, tanpa adanya proses validasi atau penyaringan yang memadai. Karena tersimpan secara permanen, serangan ini dapat berdampak pada banyak pengguna dan dapat dieksekusi tanpa memerlukan interaksi langsung dari korban.
Sebagai contoh, bayangkan jika sebuah platform seperti Facebook memiliki celah Stored XSS. Seorang penyerang bisa menyisipkan payload berbahaya ke dalam postingan. Ketika pengguna lain secara tidak sengaja melihat postingan tersebut saat scrolling, payload akan otomatis dijalankan tanpa memerlukan interaksi atau ajakan mencurigakan seperti “buka ini untuk dapat gift” atau “klik ini” “klik itu”.
Contoh lainnya, penyerang menyisipkan payload XSS ke dalam nama akun. Setiap kali profilnya dikunjungi, kode berbahaya akan dieksekusi di browser pengunjung. Atau jika payload ditanamkan di kolom komentar, maka siapa pun yang melihat komentar tersebut juga akan terdampak, atau di halaman manapun yang memanggil attribut nama akun sebagai konten yang ditampilkan.
DOM XSS (Document Object Model Cross Site Scripting) adalah jenis serangan XSS yang terjadi sepenuhnya di sisi klien (browser), tanpa melibatkan server. Serangan ini muncul ketika JavaScript di dalam halaman web secara langsung memanipulasi data dari sumber seperti URL, query string, path, atau hash (anchor) ke dalam DOM tanpa proses validasi atau encoding yang aman.
DOM XSS sering kali tampak mirip dengan Reflected XSS, namun perbedaan utamanya terletak pada tempat pemrosesan input. Pada DOM XSS, input diproses dan dieksekusi sepenuhnya di sisi klien (browser) melalui JavaScript, tanpa melalui server.
Misalkan sebuah situs memiliki URL seperti:
- https://example.com/user#admin123 → mengambil username dari hash/anchor
Dan di sisi klien terdapat kode HTML dan JavaScript berikut:
Welcome, <span id="profile">span>
<script>
const user = location.hash.substring(1);
document.getElementById("profile").innerHTML = "Welcome, " + user;
script>Jika pengguna mengakses URL berikut:
- https://example.com/user#
Maka output di halaman akan menjadi:
Welcome, <img src=x onerror=alert('XSS')>Hal ini bisa terjadi karena skrip di dalam halaman secara langsung mengambil data dari bagian hash pada URL (contoh: https://example.com/user#admin123) menggunakan location.hash, lalu menyimpannya ke dalam variabel user. Nilai tersebut kemudian dimasukkan ke dalam elemen HTML menggunakan innerHTML tanpa proses sanitasi atau validasi.
Apa itu anchor? Lihat gambar di bawah ini, bagian tersebut merupakan anchor atau sering disebut juga hash. Anchor adalah bagian dari URL yang dimulai dengan simbol # dan biasanya digunakan untuk menandai lokasi tertentu dalam sebuah halaman web. Meskipun tidak dikirim ke server, nilai anchor dapat diakses melalui JavaScript di sisi klien, dan inilah yang sering dimanfaatkan dalam serangan DOM-based XSS jika tidak ditangani dengan benar.
Reflected XSS adalah salah satu jenis Cross-Site Scripting di mana payload XSS disisipkan melalui permintaan (request) seperti parameter URL, form, atau header dan langsung “dipantulkan” kembali dalam respons halaman tanpa disimpan di server.
Cara paling umum untuk mengidentifikasi reflected XSS adalah dengan melihat apakah nilai yang dimasukkan ke dalam parameter di URL ditampilkan kembali (dipantulkan) ke halaman web. Sebagai contoh, perhatikan saat kita memasukkan string malicioustesttttttttttttt pada parameter q, dan nilai tersebut muncul dalam halaman sebagai berikut:
Sampai titik ini, kita sudah bisa mendalami lebih lanjut dengan mencoba menyisipkan tag HTML yang mampu mengeksekusi JavaScript misalnya menggunakan event handler seperti onload, onclick, onmouseover, dll atau langsung melalui tag ) agar final payloadnya dibaca sebagai tag yang valid.
Sampai tahap ini kita sudah bisa melaporkan celah tersebut. bug reported~
Jangan cuma terpaku di sini, langsung cek sendiri detail lengkap dari DursGo, karena tool ini bukan sekadar mendeteksi XSS saja. DursGo mampu menemukan berbagai jenis XSS seperti DOM-based, reflected, hingga DOM stored. Selain itu, tool ini juga mendeteksi beragam kerentanan serius lainnya seperti SQL Injection (SQLi), Command Injection, dan Server-Side Request Forgery (SSRF), serta mendukung blind vulnerability testing melalui OAST.
Tool 2 — Dalfox XSS
Dalfox adalah tool open-source yang fokus untuk mendeteksi celah XSS (Cross-Site Scripting) secara otomatis dan cepat. Tool ini sangat cocok digunakan oleh pentester maupun bug hunter karena punya mesin pengujian yang canggih dan fitur-fitur khusus yang mempermudah proses identifikasi dan validasi kerentanan.
Dalfox bisa digunakan dalam berbagai mode seperti scan lewat URL, file, payload, hingga mode server. Selain itu, Dalfox juga dilengkapi fitur analisis parameter, mining parameter tersembunyi, serta pengujian BAV (Based on Analysis and Verification). Untuk jenis XSS yang bisa dideteksi, tool ini mendukung Reflected, Stored, dan DOM-based, lengkap dengan dukungan verifikasi menggunakan browser headless.
Dalam penggunaannya, Dalfox fleksibel karena bisa diatur header, cookies, method HTTP, proxy, dan lainnya. Hasil scan bisa disimpan dalam format JSON atau teks biasa, dan tersedia juga mode silent jika tidak ingin output berisik. Selain itu, Dalfox mendukung integrasi REST API, penggunaan payload custom, dan wordlist jarak jauh, yang membuatnya mudah dikustomisasi sesuai kebutuhan pengujian [4].
Execution
Saya menggunakan perintah dasar Dalfox, dan hasilnya menunjukkan adanya reflected XSS pada parameter view. Dalfox juga menghasilkan berbagai kombinasi payload dalam jumlah yang cukup banyak.
Tool 3 — Nuclei
Nuclei adalah pemindai kerentanan yang cepat, efisien, dan dapat diperluas, mampu memindai ribuan host hanya dalam beberapa menit. Mesin Nuclei menggunakan template berbasis YAML untuk mendefinisikan langkah-langkah dalam mendeteksi kerentanan.
Sebagai alat open-source, Nuclei mendorong kontribusi dari komunitas baik dalam pembuatan template maupun pengembangan kode. Dengan demikian, setiap kali ada CVE baru yang dirilis, siapa pun dapat membuat template Nuclei dan membagikannya untuk digunakan oleh komunitas keamanan [6].
Execution
Disini saya biasanya cukup menggunakan command berikut : nuclei -u target.tld -tags xss -silent | notify -silent -bulk. Saya menggunakan parameter tags karena agar lebih fokus (mengerucut) pada vulnerability tertentu yang ingin kita cari/scan. Ya kalian bisa custom sesuai kebutuhan.
Conclusion
Kesimpulannya, baik dengan pendekatan manual maupun otomatis, tetap dibutuhkan ketelitian terutama dalam proses verifikasi finding. Setiap temuan harus diuji kembali untuk memastikan validitas dan dampaknya secara nyata.
Selain itu, Dursgo bukan hanya dapat digunakan untuk mendeteksi kerentanan XSS, tetapi juga mampu mengidentifikasi berbagai jenis kerentanan lainnya. Sedangkan Dalfox lebih berfokus secara spesifik pada eksploitasi dan deteksi XSS.
Sama halnya dengan Nuclei, yang merupakan tools scanning untuk berbagai jenis kerentanan umum (general vulnerability scanner), dan sangat efektif jika dikombinasikan dengan template yang tepat.
Great resources for improving your XSS skills :
- https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
- https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html
- https://web.archive.org/web/20241106081811/https://brutelogic.com.br/blog/
- https://xss-game.appspot.com/
- https://dojo-yeswehack.com/learn/vulnerabilities/xss
- https://x.com/hashtag/bugbountytips%20xss
- https://medium.com/search?q=Xss+bypass
- https://github.com/s0md3v/AwesomeXSS
- https://github.com/dwisiswant0/awesome-oneliner-bugbounty
Reference :
[1] https://thegray.company/blog/whats-in-an-seo-friendly-url?utm_medium=organic#url-parts
[2] https://www.assetnote.io/resources/research/advisory-citrix-gateway-open-redirect-and-xss-cve-2023-24488
[3] https://www.yeswehack.com/learn-bug-bounty/parameter-discovery-quick-guide-to-start
[4] https://github.com/roomkangali/dursgo
[5] https://github.com/hahwul/dalfox
[6] https://projectdiscovery.io/blog/ultimate-nuclei-guide
