Threats and Attacks

Co je XSS (Cross-Site Scripting)?

Cross-Site Scripting, nebo XSS, je bezpečnostní chyba na webových stránkách, která umožňuje útočníkům přidávat škodlivé skripty na webové stránky. Většinou jsou tyto skripty napsány v JavaScriptu.

Co je XSS (Cross-Site Scripting)?

Cross-Site Scripting, nebo XSS, je bezpečnostní chyba na webových stránkách, která umožňuje útočníkům přidávat škodlivé skripty na webové stránky. Většinou jsou tyto skripty napsány v JavaScriptu.

Pokud někdo navštíví stránku postiženou XSS, jeho prohlížeč spustí útočníkův skript. To může vést ke krádeži cookies, únosu relací nebo akcím provedeným bez souhlasu uživatele.

XSS, stejně jako SQL Injection, je pravidelně uváděn v OWASP Top 10 jako jedna z nejčastějších zranitelností webových aplikací.

plexicus-xss-attack-ilustration

Jak XSS funguje?

XSS často cílí na webové aplikace, které nesprávně kontrolují a čistí uživatelský vstup.

Například, pokud komentářové pole umožňuje surové HTML nebo JavaScript bez jakéhokoli filtrování, útočník by mohl přidat kód jako tento:

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

Když oběti zobrazí stránku, škodlivý kód se spustí v jejich prohlížeči.

Proč je XSS důležité v kybernetické bezpečnosti

XSS může vést k většímu narušení:

  • Převzetí účtu (krádež cookies relací k napodobení uživatelů)
  • Krádež dat (zachycení vstupů formulářů jako hesla nebo kreditní karty)
  • Phishingové útoky (vkládání falešných přihlašovacích formulářů)
  • Doručení malwaru (přesměrování uživatelů na škodlivé webové stránky)

Typy XSS

  1. DOM-Based XSS
  2. Útok probíhá zcela v prohlížeči manipulací s Document Object Model (DOM) bez zapojení serveru.
  3. Stored XSS
  4. Škodlivý skript je trvale uložen na serveru, například v databázi nebo na profilové stránce.
  5. Reflected XSS
  6. Skript je odražen z webového serveru (např. v URL nebo chybové zprávě), skript bude spuštěn, když oběť klikne na útočníky vytvořený odkaz.

Jak předcházet XSS

  • Sanitace vstupů a kódování výstupů : vždy čistit uživatelská vstupní data před jejich zpracováním, transformovat uživatelský vstup do bezpečného formátu
  • Použití Content Security Policy (CSP) : omezuje, jaké skripty mohou být spuštěny v prohlížeči.
  • Vyhnout se eval() a inline JavaScriptu : ke snížení rizik injekce.
  • Bezpečnostní testování (DAST/IAST) : provádět bezpečnostní testování k včasné detekci zranitelností

Příklad z reálného světa - Samy worm (MySpace, 2005)

Co se stalo: Samy Kamkar zveřejnil MySpace profil, který obsahoval stored XSS payload. Když ostatní uživatelé zobrazili profil, payload se spustil v jejich prohlížečích, (a) přidal Samyho jako přítele, (b) přidal frázi „Samy je můj hrdina“ na jejich profily a (c) replikoval se na stránky profilů těchto uživatelů.

Dopad: Červ se sám rozšířil na ~1 milion uživatelů během ~20 hodin, což dočasně vyřadilo MySpace z provozu.

Proč to fungovalo: MySpace umožňoval neescapovaný HTML/atributy v polích profilů, což umožnilo spuštění uloženého skriptu v prohlížečích návštěvníků.

Lekce / oprava: Správné kódování výstupu, sanitizace vstupu, odstranění HTML v profilech a rychlé záplatování. Samy později čelil právním důsledkům a MySpace nasadil filtry.

Související termíny

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)