Threats and Attacks

Hvad er XSS (Cross-Site Scripting)?

Cross-Site Scripting, eller XSS, er en sikkerhedsfejl på hjemmesider, der lader angribere tilføje skadelige scripts til websider. Ofte er disse scripts skrevet i JavaScript.

Hvad er XSS (Cross-Site Scripting)?

Cross-Site Scripting, eller XSS, er en sikkerhedsfejl på hjemmesider, der lader angribere tilføje skadelige scripts til websider. Ofte er disse scripts skrevet i JavaScript.

Hvis nogen besøger en side, der er påvirket af XSS, kører deres browser angriberens script. Dette kan resultere i stjålne cookies, kaprede sessioner eller handlinger udført uden brugerens tilladelse.

XSS, ligesom SQL Injection, er regelmæssigt opført i OWASP Top 10 som en af de mest almindelige sårbarheder i webapplikationer.

plexicus-xss-attack-ilustration

Hvordan fungerer XSS?

XSS retter sig ofte mod webapplikationer, der ikke korrekt kontrollerer og renser brugerinput.

For eksempel, hvis en kommentarboks tillader rå HTML eller JavaScript uden nogen filtrering, kunne en angriber tilføje kode som denne:

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

Når ofrene ser siden, kører den skadelige kode i deres browser.

Hvorfor XSS er vigtigt i cybersikkerhed

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

  • Kontoovertagelse (stjæle sessionscookies for at udgive sig for brugere)
  • Datatyveri (opsnappe formularinput som adgangskoder eller kreditkort)
  • Phishing-angreb (indsprøjte falske loginformularer)
  • Malware-levering (omdirigere brugere til skadelige hjemmesider)

Typer af XSS

  1. DOM-baseret XSS
  2. Angrebet sker udelukkende i browseren ved at manipulere Document Object Model (DOM) uden at involvere serveren.
  3. Lageret XSS
  4. Ondsindet script er permanent lagret på serveren, såsom i databasen, profilside.
  5. Reflekteret XSS
  6. Script reflekteres fra en webserver (f.eks. i URL eller fejlmeddelelse), scriptet vil blive udført, når offeret klikker på et manipuleret link af angribere.

Hvordan man forhindrer XSS

  • Input-sanitization & output-kodning: altid rense brugerinputdata før behandling, transformere brugerinput til et sikkert format
  • Brug Content Security Policy (CSP): begrænser hvilke scripts der kan udføres i browseren.
  • Undgå eval() og inline JavaScript: for at reducere injektionsrisici.
  • Sikkerhedstestning (DAST/IAST): kør sikkerhedstestning for at opdage sårbarheder tidligt

Eksempel i virkelige verden - Samy worm (MySpace, 2005)

Hvad skete der: Samy Kamkar offentliggjorde en MySpace-profil, der indeholdt en lagret XSS-payload. Når andre brugere så profilen, kørte payloaden i deres browsere, den (a) tilføjede Samy som ven, (b) tilføjede sætningen “Samy is my hero” til deres profiler, og (c) replikerede sig selv til disse brugeres profilsider.

Indvirkning: Ormen selv-replikerede til ~1 million brugere inden for ~20 timer, hvilket tvang MySpace offline midlertidigt.

Hvorfor det virkede: MySpace tillod uundsluppet HTML/attributter i profilfelter, hvilket muliggjorde lagret scriptudførelse i besøgendes browsere.

Lektioner / rettelser: Korrekt outputkodning, inputsanitering, fjernelse af HTML i profilfelter og hurtig patching. Samy stod senere over for juridiske konsekvenser, og MySpace implementerede filtre.

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