Reflected XSS pada Dua Parameter Berbeda di Portal Pemerintah Kabupaten [REDACTED]

1. Ringkasan Eksekutif (Executive Summary / TL;DR)

• Jenis Kerentanan: Reflected Cross-Site Scripting (XSS)
• Vektor: Parameter URL (page dan namaKategori)
• Dampak: Eksekusi JavaScript sewenang-wenang, pencurian cookie sesi (PHPSESSID), serta potensi phishing melalui dialog palsu dan redirect ke situs berbahaya.
• Status: Fixed (Reported & Acknowledged)
• Severity: Medium

2. Pendahuluan (Introduction)

Halo, saya Primandito Adi Setiya, seorang bug hunter. Pada 14 November 2025, saya sedang melakukan vulnerability testing pada portal layanan publik milik Pemerintah Kabupaten [REDACTED].

Saat menguji beberapa fitur, saya menemukan dua celah Reflected Cross-Site Scripting (XSS) pada parameter yang berbeda. Celah ini muncul karena input dari parameter URL tidak disanitasi dengan benar sebelum ditampilkan kembali ke dalam halaman HTML.

Artikel ini akan membahas bagaimana saya menemukannya, cara mereproduksinya, hingga dampak dari kerentanan ini.

3. Detail Kerentanan (Vulnerability Details)

Aplikasi menerima input dari parameter URL (seperti page dan namaKategori) dan memantulkannya (reflect) ke dalam respons halaman HTML tanpa melakukan output encoding yang tepat.

Penyerang dapat menyisipkan payload HTML/JavaScript yang akan dieksekusi oleh browser korban. Dalam kasus ini, saya menggunakan dua teknik berbeda:

1. Parameter page: Menggunakan tag <script> dengan mixed-case (<ScRiPt>) untuk mencuri cookie sesi.
2. Parameter namaKategori: Menggunakan tag <svg> dengan atribut onload untuk memicu dialog palsu dan mengarahkan korban ke situs eksternal.

4. Langkah Reproduksi (Steps to Reproduce / PoC)

A. XSS via Parameter page (Cookie Theft)

Step 1: Identifikasi Target Buka halaman berita pada target: https://redacted.kab.go.id/pages/berita?page=1

Step 2: Injeksi Payload Sisipkan payload berikut ke dalam parameter page:

"><ScRiPt>alert(document.cookie)</ScRiPt>

"><ScRiPt>alert(document.cookie)</ScRiPt>

(Payload di-encode menjadi: ?page=%22%3E%3CScRiPt%3Ealert(document.cookie)%3C/ScRiPt%3E)

Step 3: Eksekusi & Verifikasi Setelah URL diakses, muncul pop-up alert yang menampilkan cookie sesi (PHPSESSID=...), membuktikan bahwa JavaScript berhasil dieksekusi dan cookie dapat diakses.

B. XSS via Parameter namaKategori (Phishing & Redirect)

Step 4: Identifikasi Target Buka halaman artikel pada target: https://redacted.redacted.kab.go.id/index.php?r=artikel%2Findex&id=2&namaKategori=1

Step 5: Injeksi Payload Sisipkan payload berikut ke dalam parameter namaKategori:

<svg/onload="if(confirm('Session expired?')){location.href='http://testphp.vulnweb.com/'}">

<svg/onload="if(confirm('Session expired?')){location.href='http://testphp.vulnweb.com/'}">

Step 6: Eksekusi & Verifikasi Setelah URL diakses, muncul dialog confirm palsu bertuliskan "Session expired?". Jika korban menekan "OK", browser akan diarahkan ke situs eksternal (testphp.vulnweb.com).

Step 7: Verifikasi Perbaikan (Post-Fix) Setelah dilaporkan, pihak terkait merespons dengan cepat dan melakukan perbaikan. Saat ini, kedua payload tersebut sudah tidak lagi tereksekusi. Verifikasi dilakukan pada 9 Oktober 2026.

5. Dampak (Impact)

Kedua kerentanan XSS ini dapat dimanfaatkan penyerang untuk:

1. Pencurian Cookie/Session: Mencuri cookie sesi pengguna (PHPSESSID) yang berujung pada Account Takeover jika cookie tidak di-set HttpOnly.
2. Phishing: Menampilkan dialog palsu (seperti "Session expired") untuk menipu pengguna agar mengklik tautan berbahaya.
3. Redirect Berbahaya: Mengarahkan pengguna ke situs berbahaya yang dikendalikan penyerang.
4. Defacement: Mengubah tampilan halaman web sementara.

6. Rekomendasi Perbaikan (Remediation)

Untuk mencegah kerentanan ini terulang, ada tiga langkah krusial yang harus dilakukan:

1. Output Encoding: Selalu lakukan HTML entity encoding (mengubah karakter <, >, ", ', &) pada semua input yang akan ditampilkan kembali ke halaman HTML.
2. Validasi Input: Batasi karakter yang diizinkan pada parameter URL dan tolak input yang mencurigakan.
3. Content Security Policy (CSP): Terapkan CSP yang kuat untuk memitigasi dampak XSS jika terjadi.

7. Timeline (Kronologi)

• 14 November 2025: Menemukan kedua kerentanan dan melakukan verifikasi PoC.
• 14 November 2025: Melaporkan kerentanan ke pihak terkait.
• 14 November 2025: Pihak terkait memberikan respons dan konfirmasi atas laporan.
• Akhir 2025: Pihak terkait melakukan perbaikan (Fixed). Kedua payload sudah tidak tereksekusi.
• 9 Oktober 2026: Melakukan pengecekan ulang (verifikasi) dan memastikan celah sudah tertutup. Writeup dipublikasikan sebagai dokumentasi portofolio.

8. Penutup

Kerentanan ini menjadi pengingat bahwa sanitasi input pada parameter URL sangatlah krusial, terutama pada aplikasi yang menampilkan data dinamis. Saya mengapresiasi respons cepat dan komunikasi yang baik dari pihak Pemerintah Kabupaten [REDACTED] dalam menindaklanjuti laporan ini.

Bagi para bug hunter, selalu pastikan untuk menguji setiap parameter yang ada, karena satu celah bisa muncul di banyak tempat. Dokumentasi seperti ini penting untuk portofolio kita, sebagai bukti nyata kontribusi kita dalam menjaga keamanan siber. Happy hunting!