XSS je zkratka pro Cross-site Scripting (aby nedošlo k záměně s kaskádovými styly, používá se místo CSS zkratka XSS). U této techniky je snahou podstrčit stránkám svůj kód pomocí jakéhokoliv vstupu. Většinou se jedná o JavaScript, který například dokáže manipulovat s vašimi cookies a posílat citlivé údaje útočníkovi. Napadlo vás třeba, že se za neškodným avatarem může skrývat skript, který dokáže získat heslo z vaší nezabezpečené administrace ?
Jistě víte, že data v proměnné $_GET jsou předávané skriptu přes adresní řádek. Pokud nemáme dostatečně ošetřené vstupy, můžeme třeba takto dostat do stránky jednoduchý JavaScript:
skript.php?email=%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%27%58%53%53%27%29
%3C%2F%73%63%72%69%70%74%3E
Pokud se divíte, co je to za šifru, tak vězte, že to je řetězec
<script>alert('XSS')</script> převedený do
šestnáctkové soustavy. Celá adresa je pochopitelně na jeden řádek a pokud
ji ve vhodném skriptu použijete do správné proměnné, tak se vám možná
naskytne pohled na dialog s textem „XSS“. Když takovou díru objevíte, je
už jen na vaší fantazii, co všechno by se dalo pomocí JavaScriptu
udělat.
Tuhle metodu mám radši
Největší riziko představují komentáře, diskuse a
podobné stránky, kde vložený kód do formuláře bude umístěn přímo do
stránky. To pak jen přesměrování celé stránky je záležitost na pár
sekund ! Zkouška odolnosti formuláře může vypadat třeba takto:

Zvláště si všimněte obsahu kolonky „Web“ – tento způsob spoléhá na programátora, který sice ošetřil text komentáře, ale zapomněl na předchozí textové pole. Různých kombinací takových kódů je hodně, několik jich i s popisem naleznete na výborné stránce XSS Cheat Sheet.
Nejlepší obranou je důsledně ošetřovat každý vstup, používejte
proto funkce strip_tags a htmlspecialchars.
Pokud nějaký skript vkládá data od uživatele do stránky, zakažte
používání tagů script, iframe,
embed, applet a object. Toho lze
dosáhnout například pomocí regulárních výrazů. Zakázání
potencionálně nebezpečných tagů však nestačí – je třeba ještě
myslet na JavaScriptové události:
Texy! při standardním nastavení není chráněn proti XSS útoku ! Řešení je naštěstí jednoduché – stačí Texy! přepnout do bezpečného módu (řešení pro Texy2):
TexyConfigurator::safeMode($texy);
V tomto režimu jsou povoleny pouze tagy a,
acronym, b, br, cite,
code, em, i, strong,
sub, sup, q a small.
Z atributů všech tagů je povoleno pouze href,
title u odkazu a title v tagu acronym.
Bohužel jsou v tomto režimu standardně vypnuty i kaskádové styly pomocí
syntaxe Texy! – opět ale existuje řešení – stačí přidat
následující řádek pod výše zmíněný:
$texy->allowedStyles = Texy::ALL;
Vstupní data přicházejí do stránky i přes HTTP hlavičky, proto na ně nesmíme zapomenout. Představme si jednoduchou stránku vypisující identifikaci prohlížeče – mohlo by se zdát, že zde není co zkazit a stránka je bezpečná, ale zdání klame – útočník může jednoduše změnit identifikaci prohlížeče v hlavičce:
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "http://domena.cz/web-s-dirou.php");
curl_setopt($ch, CURLOPT_USERAGENT, "<script>alert('XSS')</script>");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
echo curl_exec($ch);
curl_close($ch);
Hlavičky se také dají jednoduše měnit pomocí rozšíření do Firefoxu LiveHTTPHeaders. Pak není nic jednoduššího, než třeba posílat stránce své cookies:
Cookie: email=moje+podvrzena+cookie
Obrana proti tomuto útoku spočívá opět v ošetření vstupních údajů pomocí funkcí strip_tags a htmlspecialchars.
Pokud jste všemu porozuměli, tak nyní už nezbývá nic jiného, než
zkoušet všechny tyto typy útoků na své stránky –
třeba se vám podaří najít díru a poté ji úspěšně záplatovat. Takže
hodně štěstí při obranně proti zákeřným hackerům 
| Vloženo: 29. 7. 2007 13.21 | RSS komentářů tohoto článku |
| [1] Aleš Janda (kyblicek@kyblsoft.cz) | 29. 7. 2007 22.45 |
Pěkně napsané
Třeba to vypsání prohlížeče mě nikdy nenapadlo 
Ještě bys ale mohl podotknout, v čem vlastně spočívá ta
bezpečnostní díra. Jen zobrazení textu JavaScriptem nevadí 
Jde ale o to, že JavaScriptem lze manipulovat se stránkou (přidávat komentáře atd.) s právy uživatele! Když navíc na stránku přijde admin, je to o to zajímavější.
Anebo může ukrást session – aktuální cookie (někoho jiného) odeslat na svůj server, kde to pak útočník přečte a pomocí toho se přihlásí za někoho jiného.
A ještě něco: zabránění vložení tagů script, iframe, embed a applet
nestačí. Uživatel totiž může vložit neškodný tag (třeba
<strong>), ale který má třeba mouseover, takže ten skript
se vykoná, když návštěvník přejede nad nějakým textem myší (což
není tak neobvyklé). Takže to chce zakázat nejen zmíněné tagy, ale
i všechny atributy související s JavaScriptem u všech tagů. Což už
taková sranda zase není 
Test XSS: Najeď nad tento nevinně vypadající text myší 
Tzn. tento web není zabezpečen proti XSS útoku 
| [2] Martin Grames (martin.grames@chapadlo.cz) | 31. 7. 2007 13.22 |
Ještě bys ale mohl podotknout, v čem vlastně spočívá ta bezpečnostní díra. Jen zobrazení textu JavaScriptem nevadí
Ano, to je zmíněno již v prvním odstavci – „Většinou se jedná o JavaScript, který například dokáže manipulovat s vašimi cookies a posílat citlivé údaje útočníkovi.“
Většinou se snaží z cookies ukradnout hesla nebo PHPSESSID, což už ale
souvisí s Session Hijacking a o tom někdy příště 
K tomu tvému menšímu hacku pomocí události JavaScriptu – díky, o tom jsem nikde ani nečetl. Článek jsem doplnil o nově nabyté zkušenosti a díru v komentářích záplatoval.
| [3] john | 6. 9. 2007 19.35 |
test </body> </html>
| [4] john | 6. 9. 2007 19.46 |
odkaz neodkaz zaindexuje to google?
| [5] Martin Grames (martin.grames@chapadlo.cz) | 7. 9. 2007 12.36 |
[4] john: Johne, ty myslíš, že mě dostaneš na
takových jednoduchých věcech jako
</body> </html> ? 
K tomu druhému komentáři – <strong
href="www.google.com"> – použití href ve strong jsem neviděl ani
v nejhorších nočních můrách – ono to někde funguje ?
Povolit CSS není moudré, viz http://v6ak.profitux.cz/…-na-webu.php (CSS vlastnosti -moz-binding a behavior). I CSS umožňuje XSS!