Co je XSS, jak funguje a jak se mu bránit
Autor: Redakce Domeny.ForSale Zveřejněno
Stručně: XSS (Cross-Site Scripting) je zranitelnost, kvůli které prohlížeč spouští nedůvěryhodný kód v kontextu navštívené stránky. Nejčastěji vzniká tehdy, když aplikace zachází s uživatelskými daty jako se součástí stránky nebo kódu namísto obyčejného textu. Ochrana spočívá především v bezpečném zobrazování dat, nikoli jen v blokování podezřelých vstupů.
Jak XSS funguje a co může útočník udělat
Prohlížeč interpretuje HTML jako strukturu stránky a JavaScript jako instrukce, které má provést. Pokud aplikace vloží neověřený obsah na místo, kde se interpretuje jako kód, může útočník ovlivnit fungování stránky u jiného uživatele. Zdrojem takového obsahu může být komentář, parametr adresy, název profilu nebo odpověď externí služby.
Kód spuštěný prostřednictvím XSS běží v kontextu napadeného webu. Může číst dostupná data ze stránky, měnit její obsah, zobrazovat falešný přihlašovací formulář nebo provádět operace s oprávněními přihlášeného uživatele. Skutečné následky závisí na funkcích aplikace a použitých bezpečnostních opatřeních.
Neznamená to automaticky ovládnutí serveru ani celého počítače. Problém spočívá především v tom, že prohlížeč důvěřuje kódu spouštěnému daným webem. Uživatel může otevřít správnou adresu, a přesto se dostat na stránku se škodlivým obsahem.
Tři nejčastěji popisované podoby XSS
Toto rozdělení pomáhá určit, odkud nebezpečný obsah pochází a kde ho aplikace zpracovává:
- Stored XSS neboli uložené XSS: obsah se uloží například do databáze komentářů. Problém se projeví, když ho aplikace nebezpečným způsobem zobrazí dalším lidem. Samotné uložení do databáze ještě není zranitelností.
- Reflected XSS neboli odražené XSS: aplikace převezme data z požadavku, například hledaný výraz z adresy URL, a bez odpovídající ochrany je vloží do odpovědi. Útočník může oběť přesvědčovat, aby otevřela připravený odkaz.
- DOM-based XSS: k nebezpečnému zpracování dochází v kódu JavaScript běžícím v prohlížeči. DOM je objektový model dokumentu, tedy reprezentace stránky, kterou mohou skripty číst a měnit.
Tyto kategorie se mohou překrývat. „Uložené“ a „odražené“ popisují především způsob doručení dat, zatímco „DOM-based“ označuje místo nebezpečného zpracování. Také obsah uložený v databázi může vést k DOM-based XSS.
Jednoduchý příklad: text zpracovaný jako HTML
Předpokládejme, že aplikace zobrazuje uživatelské jméno. Následující příklad spouštějte výhradně ve vlastním testovacím prostředí nebo tam, kde k tomu máte výslovný souhlas:
const jmeno = '<img src="x" onerror="alert(\'Test XSS\')">';
const element = document.querySelector('#pozdrav');
element.innerHTML = jmeno;
Vlastnost innerHTML přikazuje prohlížeči interpretovat hodnotu jako HTML. Pokud se obrázek nenačte, obsluha chyby může vyvolat alert, tedy zobrazení okna se zprávou. Jde o ukázku spuštění kódu, nikoli krádeže dat; další bezpečnostní opatření prohlížeče nebo stránky ji mohou zablokovat.
Pokud se má jméno zobrazit jako obyčejný text, správným řešením je:
const jmeno = '<img src="x" onerror="alert(\'Test XSS\')">';
const element = document.querySelector('#pozdrav');
element.textContent = jmeno;
Vlastnost textContent zobrazí zadaný řetězec, aniž by vytvořila obrázek nebo provedla instrukci v něm obsaženou. Rozdíl je zásadní: data zůstávají daty. Není třeba odhadovat, která slova nebo značky mohou být nebezpečné.
Jak chránit aplikaci před XSS
Volte ochranu podle toho, kde se data používají. Kódování výstupu spočívá v zápisu speciálních znaků tak, aby nebyly interpretovány jako součást syntaxe. Jiná pravidla platí pro text v HTML, jiná pro hodnotu atributu, adresu URL nebo úsek kódu JavaScript. Samotné nahrazení závorek < a > neochrání všechny tyto situace.
Při zobrazování obyčejného textu používejte bezpečné mechanismy šablon a rozhraní, jako je textContent. Automatické kódování ve frameworku pomáhá, ale lze ho obejít funkcí, která vkládá nezpracované HTML. Takové výjimky vyžadují samostatnou kontrolu.
Pokud uživatelé skutečně potřebují formátování pomocí HTML, použijte udržovanou knihovnu pro sanitizaci, například DOMPurify. Sanitizace odstraňuje nepovolené prvky a atributy podle stanovených pravidel. Vlastní filtr založený na několika regulárních výrazech neposkytuje rovnocennou ochranu.
Validace, tedy kontrola přípustného formátu dat, je nadále užitečná: pole pro věk by mělo přijímat číslo a adresa odkazu by měla používat povolené schéma. Nenahrazuje však bezpečné zobrazování. Nestačí ani zabezpečit pouze formulář, protože data se mohou do aplikace dostat jinou cestou.
Další vrstvy ochrany omezují následky chyb. CSP (Content Security Policy) umožňuje stanovit pravidla pro spouštění skriptů, ale její účinnost závisí na konfiguraci. Atribut HttpOnly brání čtení cookie pomocí jazyka JavaScript, nezabrání však škodlivému kódu ve všech činnostech v rámci aktivní relace.
Kde začít s kontrolou vlastního webu
Sledujte jedno pole od přijetí dat až po všechna místa, kde se zobrazují. Komentář může být bezpečný pod článkem, ale nebezpečný v panelu moderace nebo v náhledu oznámení. Zkontrolujte také použití innerHTML a funkcí umožňujících obejít automatické kódování.
Dalším krokem je test v izolovaném prostředí: zjistěte, zda se zadaný obsah zobrazí jako text, nebo změní strukturu stránky. Po opravě přidejte regresní test, který odhalí, pokud se tato data znovu začnou zpracovávat jako HTML.
Přečtěte si také
