Threats and Attacks

Apa Itu XSS (Cross-Site Scripting)?

Cross-Site Scripting, atau XSS, adalah kelemahan keamanan pada situs web yang memungkinkan penyerang menambahkan skrip berbahaya ke halaman web. Sebagian besar waktu, skrip ini ditulis dalam JavaScript.

Apa Itu XSS (Cross-Site Scripting)?

Cross-Site Scripting, atau XSS, adalah kelemahan keamanan pada situs web yang memungkinkan penyerang menambahkan skrip berbahaya ke halaman web. Sebagian besar waktu, skrip ini ditulis dalam JavaScript.

Jika seseorang mengunjungi halaman yang terpengaruh oleh XSS, browser mereka menjalankan skrip penyerang. Ini dapat mengakibatkan pencurian cookie, pembajakan sesi, atau tindakan yang dilakukan tanpa izin pengguna.

XSS, seperti SQL Injection, secara teratur terdaftar dalam OWASP Top 10 sebagai salah satu kerentanan aplikasi web yang paling umum.

plexicus-xss-attack-ilustration

Bagaimana XSS Bekerja?

XSS sering menargetkan aplikasi web yang tidak memeriksa dan membersihkan input pengguna dengan benar.

Sebagai contoh, jika kotak komentar memungkinkan HTML mentah atau JavaScript tanpa penyaringan, penyerang dapat menambahkan kode seperti ini:

<script>alert('Hacked!');</script>

Ketika korban melihat halaman tersebut, kode berbahaya berjalan di dalam browser mereka.

Mengapa XSS Penting dalam Keamanan Siber

XSS dapat menyebabkan pelanggaran yang lebih besar:

  • Pengambilalihan akun (mencuri cookie sesi untuk menyamar sebagai pengguna)
  • Pencurian data (menangkap input formulir seperti kata sandi atau kartu kredit)
  • Serangan phishing (menyuntikkan formulir login palsu)
  • Pengiriman malware (mengalihkan pengguna ke situs web berbahaya)

Jenis-jenis XSS

  1. DOM-Based XSS
  2. Serangan terjadi sepenuhnya di browser dengan memanipulasi Document Object Model (DOM) tanpa melibatkan server.
  3. Stored XSS
  4. Skrip berbahaya disimpan secara permanen di server, seperti di database, halaman profil.
  5. Reflected XSS
  6. Skrip dipantulkan dari server web (misalnya, dalam URL atau pesan kesalahan), skrip akan dieksekusi ketika korban mengklik tautan yang dibuat oleh penyerang.

Cara Mencegah XSS

  • Sanitasi input & encoding output : selalu membersihkan data input pengguna sebelum memprosesnya, mengubah input pengguna menjadi format yang aman
  • Gunakan Content Security Policy (CSP) : membatasi skrip apa yang dapat dieksekusi di browser.
  • Hindari eval() dan JavaScript inline : untuk mengurangi risiko injeksi.
  • Pengujian keamanan (DAST/IAST) : jalankan pengujian keamanan untuk mendeteksi kerentanan lebih awal

Contoh Kasus Dunia Nyata - Cacing Samy (MySpace, 2005)

Apa yang terjadi: Samy Kamkar mempublikasikan profil MySpace yang berisi payload stored XSS. Ketika pengguna lain melihat profil tersebut, payload berjalan di browser mereka, (a) menambahkan Samy sebagai teman, (b) menambahkan frasa “Samy is my hero” ke profil mereka, dan (c) mereplikasi dirinya ke halaman profil pengguna tersebut.

Dampak: Cacing tersebut menyebar sendiri ke ~1 juta pengguna dalam waktu ~20 jam, memaksa MySpace offline sementara.

Mengapa berhasil: MySpace mengizinkan HTML/atribut yang tidak di-escape di bidang profil, memungkinkan eksekusi skrip yang disimpan di browser pengunjung.

Pelajaran / perbaikan: Pengkodean keluaran yang tepat, sanitasi masukan, penghapusan HTML di bidang profil, dan penambalan cepat. Samy kemudian menghadapi konsekuensi hukum, dan MySpace menerapkan filter.

Istilah Terkait

Ready to validate what matters?

Ready to validate what matters?

Plexicus is Proof-Driven AppSec: validated findings, contextual understanding, and reviewed remediation — anchored in evidence, scoped with you.

Qualification

Check whether AI Swarm Pentest fits your environment.

Share the minimum context. We will review the scope and tell you the next commercial step.

Before submitting — verify you fit

Teams with fewer than 50 developers: start a 14-day Trial instead of booking a demo. Start a 14-day Trial →

0 / 280

No commitment. If you don't fit, we'll tell you.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorised target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)