Apa beda XSS reflected, stored, dan DOM-based?

Halaman referensi

Jawaban singkat

Reflected, stored, dan DOM-based XSS menjelaskan jalur berbeda dari data tak tepercaya ke konteks browser yang tidak aman. Ketiganya dapat tumpang tindih: periksa asal nilai, apakah disimpan, kode yang merendernya, dan pengguna yang terpapar.

Tiga jenis

Reflected XSS — nilai berada di permintaan

Nilai permintaan masuk ke respons tanpa encoding sesuai konteks lalu ditafsirkan browser sebagai markup atau skrip. Penyerang dapat mengirim tautan khusus kepada korban, tetapi akar masalahnya adalah rendering data permintaan yang tidak aman. Perbaiki output pada titik rendering.

Stored XSS — nilai disimpan

Konten tak tepercaya disimpan lalu dirender secara tidak aman kepada pengguna lain, misalnya pada komentar atau profil. Setiap pengunjung yang memuat konten itu dapat menerima konteks yang sama hingga nilai tersimpan atau jalur rendering diperbaiki.

DOM-based XSS — kode klien mengirim data ke sink DOM yang tidak aman

JavaScript sisi klien membaca sumber tak tepercaya (seperti location.hash, parameter kueri, atau data dari server) lalu menulisnya ke sink DOM tidak aman seperti innerHTML. Nilai mungkin tidak mencapai server, tetapi itu bukan syarat: DOM-based XSS menjelaskan jalur source-to-sink klien dan dapat tumpang tindih dengan cara reflected atau stored disampaikan. Perbaiki alur data klien.

Mengapa perbedaan ini penting untuk perbaikan

Perbaiki XSS pada titik rendering dengan encoding output sesuai konteks atau API DOM yang aman. Reflected dan stored XSS sering melibatkan rendering server, tetapi rendering klien juga dapat membuat sink tidak aman. Untuk DOM-based XSS, gunakan textContent alih-alih innerHTML untuk teks; jika HTML kaya diperlukan, gunakan sanitizer terawat dengan kebijakan eksplisit. Encoding server bukan pengganti peninjauan alur source-to-sink klien.

Kategori ini dapat saling tumpang tindih

Reflected dan stored menjelaskan bagaimana input mencapai halaman dan apakah nilainya tersimpan. DOM-based menjelaskan alur source-to-sink di sisi klien. Kategori ini tidak saling eksklusif: teks profil tersimpan yang dimasukkan kode klien ke innerHTML dapat menjadi XSS stored sekaligus DOM-based.

XSS DOM: sink tidak aman dan render teks saja

TIDAK AMAN — parse teks tak tepercaya sebagai HTML

const value = new URLSearchParams(location.search).get("q") ?? "";
target.innerHTML = value;

LEBIH AMAN UNTUK TEKS — tampilkan sebagai teks

const value = new URLSearchParams(location.search).get("q") ?? "";
target.textContent = value;

Referensi

Lihat juga Cross-Site Scripting (XSS, CWE-79): cara kerja dan cara mencegahnya di setiap bahasa — flawopen.com Risiko keamanan addJavascriptInterface di Android Perlindungan XSS Angular: default aman dan API bypass XSS akibat MIME sniffing: Content-Type dan nosniff CSP dan output escaping: apakah keduanya diperlukan? Apakah dangerouslySetInnerHTML di React aman? Apakah DOMPurify cukup untuk mengamankan innerHTML?