Threats and Attacks

Vad är XSS (Cross-Site Scripting)?

Cross-Site Scripting, eller XSS, är en säkerhetsbrist på webbplatser som låter angripare lägga till skadliga skript på webbsidor. Oftast är dessa skript skrivna i JavaScript.

Vad är XSS (Cross-Site Scripting)?

Cross-Site Scripting, eller XSS, är en säkerhetsbrist på webbplatser som låter angripare lägga till skadliga skript på webbsidor. Oftast är dessa skript skrivna i JavaScript.

Om någon besöker en sida som påverkas av XSS, kör deras webbläsare angriparens skript. Detta kan resultera i stulna cookies, kapade sessioner eller åtgärder som vidtas utan användarens tillstånd.

XSS, liksom SQL Injection, listas regelbundet i OWASP Top 10 som en av de vanligaste sårbarheterna i webbapplikationer.

plexicus-xss-attack-ilustration

Hur fungerar XSS?

XSS riktar sig ofta mot webbapplikationer som inte korrekt kontrollerar och rensar användarinmatning.

Till exempel, om en kommentarsruta tillåter rå HTML eller JavaScript utan någon filtrering, skulle en angripare kunna lägga till kod som denna:

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

När offer ser sidan, körs den skadliga koden i deras webbläsare.

Varför XSS är viktigt inom cybersäkerhet

XSS kan leda till ett större intrång:

  • Kontokapning (stjäla sessionscookies för att imitera användare)
  • Datastöld (fånga formulärinmatningar som lösenord eller kreditkort)
  • Phishing-attacker (injicera falska inloggningsformulär)
  • Malware-leverans (omdirigera användare till skadliga webbplatser)

Typer av XSS

  1. DOM-baserad XSS
  2. Attacken sker helt och hållet i webbläsaren genom att manipulera Document Object Model (DOM) utan att involvera servern.
  3. Lagrad XSS
  4. Skadlig kod lagras permanent på servern, såsom i databasen eller på profilsidan.
  5. Reflekterad XSS
  6. Skriptet reflekteras från en webbserver (t.ex. i URL eller felmeddelande), skriptet kommer att köras när offret klickar på en manipulerad länk av angripare.

Hur man förhindrar XSS

  • Inmatningssanering & utdata kodning: alltid rengöra användarinmatningsdata innan bearbetning, omvandla användarinmatning till ett säkert format
  • Använd Content Security Policy (CSP): begränsar vilka skript som kan köras i webbläsaren.
  • Undvik eval() och inline JavaScript: för att minska injektionsrisker.
  • Säkerhetstestning (DAST/IAST): kör säkerhetstestning för att upptäcka sårbarheter tidigt

Exempel i verkliga fall - Samy worm (MySpace, 2005)

Vad hände: Samy Kamkar publicerade en MySpace-profil som innehöll en lagrad XSS-payload. När andra användare visade profilen, kördes payloaden i deras webbläsare, den (a) lade till Samy som vän, (b) lade till frasen “Samy är min hjälte” till deras profiler, och (c) replikerade sig själv till dessa användares profilsidor.

Påverkan: Masken självförökade sig till ~1 miljon användare inom ~20 timmar, vilket tvingade MySpace att stänga ner tillfälligt.

Varför det fungerade: MySpace tillät oescapead HTML/attribut i profilfält, vilket möjliggjorde lagrad skriptkörning i besökarnas webbläsare.

Lektioner / åtgärder: Korrekt utdata kodning, inmatningssanering, borttagning av HTML i profilfält och snabb patchning. Samy ställdes senare inför rättsliga konsekvenser, och MySpace implementerade filter.

Relaterade 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)