Cross-site scripting
Cross-site scripting (XSS) – sposób ataku na serwis WWW polegający na osadzeniu w treści atakowanej strony kodu (zazwyczaj JavaScript), który wyświetlony innym użytkownikom może doprowadzić do wykonania przez nich niepożądanych akcji. Skrypt umieszczony w zaatakowanej stronie może obejść niektóre mechanizmy kontroli dostępu do danych użytkownika.
Mechanizm działania
edytujPrzeglądarki internetowe udostępniają skryptom jedynie te obiekty, które pochodzą z tego samego źródła, co strona, w której kontekście dany skrypt się wykonuje. Posługują się przy tym zasadą tożsamego pochodzenia (ang. same origin policy), która zezwala na dostęp do zasobów stron, których adres wyróżnia się takim samym protokołem, nazwą domeny serwera i numerem portu. Poniższa tabela podaje kilka przykładów stron wraz z informacją, czy ich pochodzenie jest zgodne z adresem „http://www.example.com/dir/page.html”.
| Adres | Zgodny | Komentarz |
|---|---|---|
| http://www.example.com/dir2/other.html | tak | |
| http://www.example.com/dir/inner/other.html | tak | |
| https://www.example.com/dir2/other.html | nie | inny protokół |
| http://en.example.com/dir2/other.html | nie | inny serwer |
| http://example.com/dir2/other.html | nie | inny serwer |
| http://www.example.com:81/dir2/other.html | nie | inny port |
Obostrzenia w dostępie są szczególnie istotne w przypadku ciasteczek, które bardzo często wykorzystywane są do utrwalenia uwierzytelnienia. Jeśli kod napastnika znajdzie się w treści atakowanego serwisu, posiądzie nie tylko możliwość zmodyfikowania wyglądu tej strony, ale również pozyskania i przesłania (patrz XMLHTTP) innym potencjalnie istotnych danych. Gdyby ten sam kod został umieszczony na innej stronie, przeglądarka ofiary odmówiłaby mu dostępu do zasobów związanych z atakowaną witryną.
Okoliczności występowania
edytujAby atak XSS był możliwy, witryna musi prezentować treść przekazaną od użytkownika jako kod HTML serwisu, bez uprzedniej konwersji tekstu na HTML (poprzez zamianę specjalnych znaków HTML na encje). Ochrona przed XSS poprzez samą weryfikację i filtrowanie niebezpiecznych danych jest bardzo trudna[1].
Jeśli treść zawierająca spreparowany skrypt prezentowana jest wyłącznie w odpowiedzi na to konkretne zapytanie, podatność określana jest jako non-persistent XSS i z reguły może być każdorazowo użyta tylko wobec pojedynczych ofiar. Jeśli serwis zapamiętuje przesłaną treść i prezentuje ją kolejnym odwiedzającym (np. na forum internetowym), atak określany jest jako persistent XSS i jego jednorazowe wykorzystanie może posłużyć do naruszenia bezpieczeństwa kont tysięcy użytkowników[2].
Ze względu na szeregową strukturę dokumentów HTML i trudność oddzielenia kodu JavaScript od znaczników kontrolujących prezentację treści, a także ze względu na wady przewidzianych przez JavaScript mechanizmów zabezpieczeń, podatności tego typu są niezwykle częstym problemem we współczesnych dynamicznych witrynach WWW, zwłaszcza w tak zwanych stronach Web 2.0, a ich wyeliminowanie wymaga dużej staranności.
W rzadkich sytuacjach, gdy serwis WWW nie umożliwia użytkownikom dodawania treści, wykorzystanie luki typu SQL Injection może być skuteczną metodą przeprowadzenia ataku persistent XSS. Umożliwia to zmianę danych zapisanych w bazie danych, a w konsekwencji przyczynia się do rozprzestrzenienia złowrogiego skryptu na wszystkich użytkowników strony[3].
Przykłady
edytujWraz z upowszechnianiem się aplikacji webowych, rośnie liczba doniesień o podatności istotnych serwisów na ataki XSS. Poniżej kilka przykładów:
- Dwie luki w bezpieczeństwie wyszukiwarki Google zostały opublikowane w grudniu 2005 roku przez Yaira Amita[4]. Błędy typu non-persistent XSS pozwalały atakującemu na umieszczenie dowolnie wybranej treści na stronach firmy Google. Atak ten mógł zostać np. wykorzystany do przygotowania specjalnej strony pozyskującej dane użytkowników przy pomocy techniki phishingu.
- Ataki non-persistent XSS, wykorzystujące luki w stronach internetowych magazynów CBS News i BBC, umożliwiły w sierpniu 2006 rozpowszechnienie fałszywej informacji o nominacji dziewięciolatka na szefa departamentu bezpieczeństwa informatycznego w USA[5].
- Luka w algorytmach filtrujących kod HTML w mailach przychodzących do użytkowników systemu pocztowego Hotmail pozwalała w październiku 2001 atakującemu na kradzież ciasteczek potwierdzających autoryzację w profilu Windows Live ID[6]. Choć problem został szybko naprawiony, podobne luki pojawiały się w innych usługach, których uwierzytelnienie oparte było na usłudze .NET Passport.
- 4 października 2005 wirus Samy rozprzestrzenił się (przy pomocy ataku persistent XSS) w portalu MySpace, w wyniku czego miliony użytkowników nieświadomie wysłały prośbę o dodanie do grona swoich przyjaciół twórcy wirusa – Samy’ego Kamkara oraz rozesłała wirusa do pozostałych swoich znajomych[2].
- W styczniu 2008 luka non-persistent XSS w internetowym serwisie włoskiego banku Banca Fideuram umożliwiała podmianę fragmentu strony logowania[7]. Umożliwiło to atakującym przygotowanie trudnego do wykrycia phishingu, w którego następstwie użytkownicy mogli nieświadomie przekazać swoje dane autoryzacyjne osobom postronnym.
Zobacz też
edytujPrzypisy
edytuj- ↑ XSS (Cross Site Scripting) Cheat Sheet. [dostęp 2008-02-16]. [zarchiwizowane z tego adresu (2012-09-11)].
- ↑ a b Technical explanation of The MySpace Worm. [dostęp 2007-06-24]. [zarchiwizowane z tego adresu (2015-09-24)].
- ↑ YouTube [online], www.youtube.com [dostęp 2017-11-22] (fr.).
- ↑ Yair Amit, XSS vulnerabilities in Google.com.
- ↑ George Bush appoints a 9 year old to be the chairperson of the Information Security Deportment. [dostęp 2007-07-14]. [zarchiwizowane z tego adresu (2007-01-29)].
- ↑ Microsoft Passport to Trouble [online], www.znep.com [dostęp 2017-11-22].
- ↑ Italian Bank’s XSS Opportunity Seized by Fraudsters | Netcraft [online], news.netcraft.com [dostęp 2017-11-22] (ang.).