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#<img src=x onerror=alert(‘XSS’)>
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: <textarea ****>malicioustesttttttttttttt</textarea>
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 <script>. Jika tidak ada mekanisme sanitasi, maka serangan XSS dapat terjadi.
Namun, apakah kita harus melakukan proses ini secara manual dan berulang untuk setiap target? Di sinilah peran tools otomatis seperti Dalfox, Nuclei, dan Dursgo untuk mengurangi proses yang repetitif dan meningkatkan efisiensi pencarian celah XSS.
Exploitation
Manual Method
Tapi kita coba dulu secara manual mencari kerentanan XSS pada target yang telah kita tentukan di awal (inisiasi target), seperti pada umumnya orang-orang saya melakukan subdomain enumeration, crawling, parameter scan, dll, kemudian saya memilih salah satu subdo sebagai contoh (purchase).
Disini saya fokus mencari subdo yang memiliki kata kunci location karena sering terjadi dom/reflected xss datang nya dari function tersebut. dan ditemukanlah subdomain berikut :
Kalau kita lihat dari view-source di atas, itu kita sudah menemukan celah open-redirect dimana jika terdapat parameter loginUrl maka diarahkan ke value loginUrl tersebut melalui mekanisme window.location.href.
Lalu apakah bisa XSS? ya bisa cukup kita ganti saja value nya menjadi payload xss paling umum digunakan pada mekanisme redirect adalah : javascript:alert(1) []. jadi ketika ada inputan http://redacted.tld/?loginUrl=javascript:alert(1); yang sebenarnya terjadi di js nya adalah seperti berikut:
Sampai tahap ini kita sudah berhasil mendapatkan kerentanan DOM XSS.
Assistive tools
Andai hasil view-source tadi susah dibaca, atau kita belum terbiasa baca/analisa source code, apakah tetap bisa mendapatkan XSS? ya kita bisa analisis hidden parameter menggunakan berbagai alat, seperti Arjun, Paramspider, atau param-miner kalau pakai nya di burpsuite [3].
Mari kita coba pakai arjun, disini justru kita mendapatkan parameter ‘view’ dan ‘org’ yang mana tidak ditemukan secara visibel pada view-source sebelum nya.
Jika kita akses kedua parameter tersebut ternyata direfleksikan langsung ke halaman, terlebih apapun inputan dari parameter tidak dilakukan sanitasi, sehingga sampai tahap ini kita sudah dapat juga Reflected XSS.
Check your understanding : sudah cukup tahu kan perbedaan ref & dom xss? lihat saja gambar dom xss sebelumnya, ketika saya menginputkan javascript:alert(1) di parameter meskipun tanpa terefleksi ke halaman tapi tetap tereksekusi.
Tool 1 — Dursgo
DursGo adalah pemindai keamanan aplikasi web yang dirancang khusus untuk kebutuhan penetration testing dan audit keamanan otomatis. Dibangun menggunakan bahasa Go, DursGo memadukan performa tinggi dengan analisis berbasis AI untuk memberikan wawasan keamanan yang cerdas, kontekstual, dan dapat ditindaklanjuti [4].
Fitur Utama
Pemindaian Kontekstual & AI-Powered Analysis
Menggunakan LLM (seperti Gemini dan Groq) untuk memberikan analisis mendalam, akar masalah, serta saran perbaikan kode pada kerentanan yang ditemukan.
Dukungan Autentikasi Lengkap
Mendukung berbagai metode autentikasi seperti:
- Login Form (Form-Based)
- Cookie Session
- Header Token (API Key, Bearer Token)
- Custom Header (X-Auth-Token)
OAST (Out-of-Band Testing)
Deteksi kerentanan “blind” seperti:
- Blind SSRF (
blindssrf) - Blind Command Injection (
cmdinjection) - Dilengkapi integrasi otomatis dengan Interactsh.
Render JavaScript untuk DOM XSS
Dengan --render-js, DursGo mampu mendeteksi:
- DOM-Based XSS (
domxss)
Cocok untuk Single Page Applications (SPA) berbasis JavaScript.
Modul Pemindai Kerentanan yang Lengkap
DursGo mampu mendeteksi berbagai jenis kerentanan, termasuk:
OWASP Top 10:
xss(Reflected & Stored)sqli(SQL Injection)idor(Insecure Direct Object Reference)csrf(Cross-Site Request Forgery)lfi(Local File Inclusion)ssrf(Server-Side Request Forgery)ssti(Server-Side Template Injection)massassignmentopenredirectcors(Misconfiguration)exposed(Sensitive files/directories)
API & Modern Scanner:
graphql(introspection, injection, schema abuse)bola(Broken Object Level Authorization)fileupload(Unrestricted Upload)securityheaders(Missing/Misconfigured Headers)
Execution
Back to judul ya, disini saya fokus nya mencari XSS, adapun command yang saya pakai menggunakan sample yang ada pada readme, hasilnya cukup cepat (sekitar 1 menit — tapi ini tergantung crawling juga) dan akurat dimana hanya dengan menginputkan target subdo/domain sudah bisa mendapatkan kerentanan XSS.
Meskipun dianggap vuln sama tool yang dipakai, Tapi ketika diakses kok ga reflect? justu nampilin random text? saya yakin jika kita tidak memiliki fundamental xss/web basic, modal paste payload > gada popup > skip (tanpa validasi ulang). Dampak nya, potensi-potensi xss akan terlewatkan (mungkin berakhir di tangan bug hunter yang lebih telaten & jago).
Perhatikan di atas ya, jika kita view-source disitu akan terlihat, bahwasanya opening tag <script> masuk sebagai string biasa (bukan tag yang valid), sehinga apa yang dapat kita lakukan adalah : modifikasi payload dengan menambahkan close tag (</script>) 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
