Artikel ini membahas cara menguji DOM & Stored XSS menggunakan Eruda (mobile devtools), termasuk contoh payload yang berpotensi menjadi stored di server. Disertai langkah aman dan template laporan bug bounty. Jangan lakukan pengujian tanpa izin tertulis dari pemilik situs.

Ringkasan cepat

• Eruda: devtools untuk browser mobile; berguna untuk inspeksi DOM, console, dan network.
• Stored XSS: terjadi apabila input yang kamu kirim ke server disimpan (database/file) lalu ditampilkan ke pengguna lain tanpa sanitasi.
• Selalu mulai dengan payload non-eksekusi (marker) sebelum mencoba eksekusi JS.

Contoh payload yang bisa menjadi stored di server

Berikut contoh payload yang sering disimpan (stored) bila dikirim melalui form, API, atau field profil. Saya bagi menjadi tiga kategori: non-eksekusi (marker), struktur HTML (non-exec), dan POC eksekusi. Gunakan POC eksekusi hanya dengan izin.

1) Payload marker — aman untuk verifikasi penyimpanan

Tujuan: membuktikan bahwa input tersimpan dan dirender kembali sebagai HTML atau teks.

<!-- Marker sederhana -->
MARKER_TEST_2025
<!-- Contoh dikirim sebagai isi komentar / bio -->

2) Struktur HTML non-eksekusi — tunjukkan rendering HTML

Jika server menyimpan HTML mentah, tag custom/element akan terlihat di DOM (meski tidak mengeksekusi JS).

<test-POC>SAVED_OK</test-POC>
<div class="poc-sample">POC_STORED_1</div>

3) POC eksekusi (alert) — hanya dengan izin

Digunakan untuk bukti eksekusi JavaScript pada client. Jangan gunakan payload yang mengambil data.

<svg onload=alert('POC_STORED_2025')>
<img src=x onerror=alert('POC_STORED_2025')>
"><script>alert('POC_STORED_2025')</script>

4) Encoding & variasi (URL-encoded / HTML-encoded)

Kadang server meng-encode nilai; contoh format URL-encoded:

%3Csvg%20onload%3Dalert('POC_STORED_2025')%3E
%3Ctest-POC%3ESAVED_OK%3C%2Ftest-POC%3E

Atau HTML-entity encoded (sering dipakai server sanitasi sederhana):

<script>alert('x')</script>

Cara mengirim payload ke server dengan aman (Eruda / fetch / Burp)

Berikut contoh metode yang biasa dipakai untuk submit payload. Gunakan akun test atau staging.

1) Mengisi form lalu submit (Eruda Console)

// Contoh: isi textarea comment lalu submit
document.querySelector('textarea[name=comment]').value = '<test-POC>SAVED_OK</test-POC>';
document.querySelector('form#commentForm').submit();

Catat: Jika form memakai CSRF token, submit akan validasi — lakukan lewat akun test.

2) Mengirim langsung lewat fetch (console / Eruda)

fetch('/api/comments', {
  method: 'POST',
  headers: {'Content-Type': 'application/json'},
  body: JSON.stringify({comment: '<test-POC>SAVED_OK</test-POC>'})
}).then(r => r.text()).then(console.log)

Gunakan path API yang valid untuk target — jangan kirim ke endpoint yang melakukan tindakan sensitif (transfer, hapus, dsb.).

3) Intercept & modify request dengan Burp (direkomendasikan untuk kontrol)

1. Jalankan Burp dan set browser/proxy ke Burp.
2. Intercept request submit komentar / profile update.
3. Ubah body/parameter menjadi payload marker / POC.
4. Forward dan cek page yang menampilkan data.

Burp memberi kontrol penuh pada header, body, dan melihat response server secara langsung.

Langkah verifikasi stored XSS (safe workflow)

1. Gunakan akun test / staging.
2. Submit payload marker (contoh: <test-POC>SAVED_OK</test-POC>).
3. Kunjungi halaman yang menampilkan data (atau tunggu background job selesai bila ada delay).
4. Inspect DOM — cari tag marker atau teks yang tersimpan. Ambil screenshot lengkap (URL terlihat, payload di form, dan hasil render).
5. Jika program bounty mengizinkan POC eksekusi, ulangi dengan payload exec (alert) dan rekam video/screenshot saat alert muncul.
6. Jangan publikasi payload yang mengandung data sensitif; dokumentasikan hasil untuk laporan internal / bounty.

Contoh template bukti untuk laporan (Stored XSS)

Judul: Stored XSS pada field komentar di /posts/1234

Ringkasan:
Saya menemukan bahwa input komentar disimpan di database dan dirender tanpa sanitasi pada halaman /posts/1234 sehingga memungkinkan eksekusi JS.

Langkah reproduksi:
1. Login sebagai akun test 'tester1'.
2. Buka https://target.example.com/posts/1234
3. Isi komentar dengan payload: <test-POC>SAVED_OK</test-POC> lalu submit.
4. Buka ulang halaman https://target.example.com/posts/1234 — element <test-POC>SAVED_OK</test-POC> muncul di DOM (lihat screenshot_1.png).
5. (Jika diizinkan) Uji POC exec: "><svg onload=alert('POC')> — alert muncul (lihat video_1.mp4).

Dampak:
Persistent XSS — setiap pengunjung halaman akan mengeksekusi JS berbahaya yang bisa mencuri cookie atau melakukan aksi atas nama user.

Rekomendasi:
- Escape output pada server (HTML-escape) atau gunakan DOMPurify jika HTML dibutuhkan.
- Terapkan Content-Security-Policy yang ketat.
- Validasi input pada server dan gunakan whitelist jika menerima HTML.

Mitigasi dan rekomendasi developer

• Sanitasi semua input sebelum disimpan jika data itu akan disajikan sebagai HTML. Gunakan library tepercaya (contoh: DOMPurify untuk client-side sanitasi; server-side gunakan parser/sanitizer sesuai stack).
• Untuk teks biasa, gunakan textContent saat merender di client.
• Jangan menyimpan HTML mentah kecuali ada kebutuhan kuat dan mekanisme sanitasi yang jelas.
• Audit semua titik penyimpanan user input: komentar, profil, deskripsi produk, dsb.
• Terapkan CSP, batasi sumber script, dan hindari unsafe-inline.

FAQ singkat terkait payload stored XSS

Apa payload terbaik untuk bukti awal?

Gunakan marker non-eksekusi seperti <test-POC>SAVED_OK</test-POC>. Ini aman dan cukup menunjukkan bahwa HTML disimpan.

Bagaimana cara memastikan itu benar-benar 'stored'?

Setelah submit, logout atau gunakan browser lain, lalu buka halaman target. Jika payload masih terlihat → itu stored (tersimpan server-side).

Bolehkah saya gunakan payload exfiltration untuk membuktikan dampak?

Tidak. Exfiltration (mengirim cookie/data ke server attacker) melanggar etika dan biasanya aturan bounty. Gunakan alert() atau bukti non-sensitif lain jika program mengizinkan.