threats.pl > Bezpieczeństwo aplikacji internetowych > Lekcja 1: Absolutne podstawy

Lekcja 1: absolutne podstawy

Lekcja ta dotyczy absolutnych podstaw związanych z funkcjonowaniem protokołu HTTP oraz doborem narzędzi. Ani ta, ani żadna kolejna lekcja nie jest przewodnikiem włamywania się, więc jeśli tego szukasz - źle trafiłeś. Informacje tu zawarte nie są również wyczerpujące. W założeniu jest to prosty przewodnik dla osób rozpoczynających swoją przygodę z tematem bezpieczeństwa aplikacji internetowych.

Narzędzia

Dla uproszczenia przyjmijmy, że aplikacja internetowa (wraz z "środowiskiem") składa się z:

Serwer pozostaje zwykle poza kontrolą atakującego, a jedynym sposobem na interakcję z aplikacją jest wysyłanie odpowiednich żądań HTTP.

Przeglądarka internetowa działa w środowisku całkowicie kontrolowanym przez atakującego. Nie można uznawać "zabezpieczeń" wprowadzonych po stronie klienta (w przeglądarce) za jakiekolwiek zabezpieczenie, ponieważ atakujący może dowolnie modyfikować sposób ich działania.

Kanał komunikacji jest niezaufany, ponieważ pozostaje pod kontrolą atakującego. Atakujacy może zmienić dowolny element żądania lub odpowiedzi między przeglądarką i serwerem. Wprowadzenie HTTPS nie zmienia tej sytuacji, dlatego też wszystkie dane przychodzące od klienta należy traktować jako niezaufane. Czytaj więcej o Trust Boundary.

Local proxy

Podstawowe narzędzie wykorzystywane do badania aplikacji internetowej to narzędzie typu local proxy, które przechwytuje komunikację między serwerem a przeglądarką i pozwala na jej dowolną modyfkację. Przykłady tego typu narzędzi to:

W tym przewodniku wykorzystywać będę przede wszystkim narzędzie Fiddler oraz sporadycznie BurpSuite. Fiddler nie jest typowym narzędziem przeznaczonym do testów penetracyjnych, w związku z czym brak mu pewnych funkcji dostępnych w WebScarab czy Burp, jednak uważam, że to właśnie Fiddler zapewnia największą wygodę pracy (przynajmniej dla mnie). W zasadzie jedynym (potencjalnym) problemem jest fakt, że aplikacja ta przeznaczona jest dla systemu Windows.

By rozpocząć pracę, należy pobrać:

Okresowo warto przeglądać listę rozszerzeń, dostępna jest ona na stronie Fiddler - Extensions.

W przykładach będę korzystał z przeglądarki Internet Explorer 8. Po zainstalowaniu Fiddler będzie to wyglądało mniej więcej tak:

Po uruchomieniu Fiddler wygląda mniej więcej tak:

W pewnym zakresie można dostosowywać jego wygląd i zachowanie. Istotne elementy interfejsu:

Więcej informacji o interfejsie narzędzia: The Fiddler User Interface.

Po uruchomieniu przeglądarki i Fiddlera, można otworzyć link do pierwszej pomocy naukowej: http://bootcamp.threats.pl/lesson01/index.php

Żądanie wysłane przez przeglądarkę zostanie przechwycone przez Fiddler, pojawi się pierwszy element na liście sesji:

W tej chwili można przejść do poznawania podstaw protokołu HTTP. Warto zaznaczyć w Fiddler opcję Rules - Remove All Encodings.

Narzędzia developerskie

W procesie testowania bezpieczeństwa aplikacji przydatne mogą być również narzędzia developerskie przeznaczone przede wszystkim dla programistów (webmasterów). Obecnie narzędzia takie dostępne są w typowych przeglądarkach:

Narzędzia te mogą być przydatne przy modyfikacji DOM dokumentu czy analizie skryptów.

Podstawy protokołu HTTP

Dwa podstawowe elementy to:

Żądanie HTTP

Żądanie wysłane przez przeglądarkę w celu pobrania wskazanej strony wygląda (po drobnych skrótach) w sposób następujący (Inspectors, Raw): 
GET /lesson01/index.php HTTP/1.1
Accept: image/gif, image/jpeg, (...)
Accept-Language: en-US,pl;q=0.5
User-Agent: Mozilla/4.0 (compatible; ...)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: bootcamp.threats.pl

W pierwszej linii znajduje się kolejno metoda (GET) adres pobieranego zasobu (bez nazwy hosta), wersja protokołu HTTP (HTTP/1.1). Kolejne linie żądania to tak zwane nagłówki. Ich struktura jest prosta - nazwa i po dwukropku wartość. W tym wypadku przeglądarka informuje serwer o akceptowanych przez siebie typach plików (Accept), języku (Accept-Language), swojej wersji (User-Agent), akceptowanych kodowaniach (Accept-Encoding). Nagłówek Host mówi o hoście, z którym się przeglądarka łączy oraz o tym, że z powodów wydajnościowych przeglądarka chce utrzymać otwarte połączenie z serwerem (Connection: Keep-Alive).

Odpowiedź HTTP

W odpowiedzi na żądanie klienta, serwer zwraca następującą odpowiedź:

HTTP/1.1 200 OK
Server: IdeaWebServer/v0.60
Date: Mon, 30 Mar 2009 16:16:38 GMT
X-Powered-By: PHP/5.2.6
Set-Cookie: SampleCookie1=CookieValue
Set-Cookie: SampleCookie2=CookieValue; expires=Mon, 30-Mar-2009 17:16:38 GMT
Content-Type: text/html
Connection: Keep-Alive
Content-Length: 2001

Po tej treści znajduje się jeszcze dwie puste linie i treść strony, w tym przypadku nieistotne.

W pierwszej linii znajduje się informacja o statusie żądania, w tym przypadku żądanie zakończyło się powodzeniem, zwrócony został kod 200 OK.

W kolejnych liniach znana już konstrukcja z nazwą nagłówka i jego wartością. W tym przypadku można się dowiedzieć, że:

Dodatkowo warto zwrócić uwagę na dwa nagłówki Set-Cookie, które służą właśnie do ustawienia cookies. W tym wypadku ustawiane są dwa cookies o nazwach SampleCookie1 oraz SampleCookie2. Różnica między nimi jest taka, że pierwsze cookie to cookie sesyjne - nie ma określonej daty wygaśnięcia, "zniknie" więc po wyłączeniu przeglądarki. W drugim przypadku cookie pozostanie "ważne" (a przynajmniej będzie zwracane przez przeglądarkę do serwera) do czasu określonego w atrybucie expires.

Proponuję poklikać sobie na poszczególnych zakładkach Fiddlera by zapoznać się z jego możliwościami i sposobem, w jaki prezentuje żądanie i odpowiedź serwera (na zakładce Inspectors).

Przekazywanie parametrów

W początku swojego istnienia strony WWW były statyczne. Z czasem sytuacja ta uległa zmianie, a statyczne strony WWW zmieniły się w rozbudowane aplikacje, z którymi użytkownik może wchodzić w interakcję. W związku z tym poza wywoływaniem statycznych plików, konieczne stało się przekazywanie parametrów do aplikacji. Istnieją dwie podstawowe metody przekazania parametrów:

Przygotowana przeze mnie przykładowa strona zawiera w sobie:

Przekazywanie metodą GET

Parametry przekazywane metodą GET umieszczane są w adresie strony po znaku ? i rozdzielone znakiem &. Parametry są zwykle przekazywane w postaci par nazwa=wartość. Ponieważ w nazwie lub wartości parametru mogą pojawić się znaki, które nie są dozwolone w adresie lub mają w tym kontekście specjalne znaczenie, stosowany jest tak zwany url encoding. Na zakładce Inspectors - Web Forms dane są odkodowywane i prezentowane w łatwej do przeglądania i edycji postaci.

Dla porównania te same dane w postaci "surowej". Przy okazji warto zwrócić uwagę na nagłówek Referer, w której znajduje się adres strony, z której nastąpiło odwołanie. Jak widać widoczny w niej jest cały URL razem z parametrami przekazanymi w GET. Właśnie z powodu możliwości ujawnienia danych, nie tylko w nagłówku Referer, ale choćby w logach serwera WWW czy serwera proxy, nie należy stosować przekazywania parametrów metodą GET, a przynajmniej nie należy w ten sposób przekazywać istotnych danych jak na przykład hasła czy identyfikatory sesji.

Przekazywanie metodą POST

W przypadku przekazywania parametrów metodą POST, nazwy i wartości parametrów nie są widoczne w adresie URL. Tym razem najpierw w postaci "surowej":

Oczywiście dane przekazywane metoda POST można przedstawić w równie łatwej do czytania i edycji postaci:

Więcej informacji

Więcej informacji na temat protokołu HTTP: HTTP References

Edycja żądania, czyli klient (atakujący) kontroluje WSZYSTKO

Do tej pory Fiddler był wykorzystywany wyłącznie do monitorowania ruchu między przeglądarką i serwerem. Jak zmodyfikować przekazywane dane? W tym celu wystarczy przechwycić żądanie ustawiając Rules - Automatic Breakpoints - Before Requests. W tej chwili Fiddler przechwyci żądanie generowane przez przeglądarkę i będzie możliwość jego edycji przed przesłaniem do serwera:

Jak widać można edytować każdy element żądania HTTP, w tym przypadku (obrazek) do edycji dostępne są parametry - można dopisać parametr, usunąć parametr, zmienić nazwę lub wartość. Na zakładce Headers można modyfikować dowolny nagłówek żądania, na zakładce TextView można edytować natomiast "body" żądania (czyli w praktyce w przypadku metody POST - parametry).

Po edycji można albo pozwolić zakończyć się żądaniu (Run to Completion), albo przechwycić i edytować odpowiedź serwera (Break on Response).

Możliwości rozszerzania Fiddlera

Fiddler może być w łatwy sposób rozszerzany. Poszerzanie jego funkcjonalności możliwe jest na kilka różnych sposobów. Temat ten jest opisany na stronie Developer Info.

W wielu przypadkach przydatny może okazać się mechanizm FiddlerScript. Dzięki niemu możliwe jest na przykład łatwe pominięcie/ukrycie części sesji, które w danej chwili nie są istotne. Może to być szczególnie przydatne w przypadku nowych aplikacji korzystających intensywnie z AJAX i okresowo odświeżających pewne informacje.

Rozszerzenia pozwalają automatyzować i ułatwiać niektóre z zadań. Przykład wykorzystania takiego rozszerzenia jest pokazany we wpisie Jak szukać SQLi - przykład. W tym przypadku wykorzystane zostało rozszerzenie, które pozwalało w łatwy sposób znaleźć te sesje, które w trakcie fuzzingu dały inną odpowiedź od oczekiwanej.

Videocast

Przykład wykorzystania narzędzia Fiddler.

Podsumowanie

Po tym krótkim wprowadzeniu do podstaw powinieneś umieć: