Threats and Attacks

Hva er XSS (Cross-Site Scripting)?

Cross-Site Scripting, eller XSS, er en sikkerhetsfeil på nettsteder som lar angripere legge til skadelige skript på nettsider. Som oftest er disse skriptene skrevet i JavaScript.

Hva er XSS (Cross-Site Scripting)?

Cross-Site Scripting, eller XSS, er en sikkerhetsfeil på nettsteder som lar angripere legge til skadelige skript på nettsider. Som oftest er disse skriptene skrevet i JavaScript.

Hvis noen besøker en side som er påvirket av XSS, kjører nettleseren deres angriperens skript. Dette kan resultere i stjålne informasjonskapsler, kaprede økter, eller handlinger utført uten brukerens tillatelse.

XSS, som SQL Injection, er jevnlig oppført i OWASP Top 10 som en av de vanligste sårbarhetene i webapplikasjoner.

plexicus-xss-attack-ilustration

Hvordan fungerer XSS?

XSS retter seg ofte mot webapplikasjoner som ikke korrekt sjekker og renser brukerinput.

For eksempel, hvis en kommentarboks tillater rå HTML eller JavaScript uten noen form for filtrering, kan en angriper legge til kode som dette:

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

Når ofre ser siden, kjører den skadelige koden i nettleseren deres.

Hvorfor XSS er viktig i cybersikkerhet

XSS kan føre til et større brudd:

  • Kontoovertakelse (stjeling av sesjonskapsler for å utgi seg for brukere)
  • Datatyveri (fange opp skjemainput som passord eller kredittkort)
  • Phishing-angrep (injisere falske innloggingsskjemaer)
  • Malware-levering (omdirigere brukere til skadelige nettsteder)

Typer av XSS

  1. DOM-basert XSS
  2. Angrepet skjer helt i nettleseren ved å manipulere Document Object Model (DOM) uten å involvere serveren.
  3. Lagret XSS
  4. Ondsinnet skript lagres permanent på serveren, for eksempel i databasen eller på profilsiden.
  5. Reflektert XSS
  6. Skriptet reflekteres fra en webserver (f.eks. i URL eller feilmelding), skriptet vil bli utført når offeret klikker på en spesiallaget lenke av angripere.

Hvordan forhindre XSS

  • Inndatasanitering og utgangskoding: alltid rengjøre brukerinndata før behandling, transformere brukerinndata til et trygt format
  • Bruk Content Security Policy (CSP): begrenser hvilke skript som kan kjøres i nettleseren.
  • Unngå eval() og inline JavaScript: for å redusere injeksjonsrisiko.
  • Sikkerhetstesting (DAST/IAST): kjør sikkerhetstesting for å oppdage sårbarheter tidlig

Eksempel i virkelige tilfeller - Samy-ormen (MySpace, 2005)

Hva skjedde: Samy Kamkar publiserte en MySpace-profil som inneholdt en lagret XSS-nyttelast. Når andre brukere så profilen, kjørte nyttelasten i nettleserne deres, den (a) la til Samy som venn, (b) la til setningen “Samy is my hero” til profilene deres, og (c) replikerte seg selv til disse brukernes profilsider.

Innvirkning: Ormen selvreplikerte til ~1 million brukere innen ~20 timer, noe som tvang MySpace offline midlertidig.

Hvorfor det fungerte: MySpace tillot uescaped HTML/attributter i profilfeltene, noe som muliggjorde lagret skripteksekvering i besøkendes nettlesere.

Leksjoner / fiks: Riktig utgangskoding, inndatakontroll, fjerning av HTML i profilfelt, og rask oppdatering. Samy møtte senere juridiske konsekvenser, og MySpace implementerte filtre.

Relaterte Termer

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)