Testowanie bezpieczeństwa aplikacji internetowych – część 2: Analiza funkcjonalności aplikacji
[24-09-2007]
Tematem tej części można byłoby pewnie wypełnić książkę, tutaj ograniczę się do bardzo skrótowego ujęcia. Analiza funkcjonalności polegać będzie na skatalogowaniu akcji dostępnych w serwisie, a następnie określeniu zagrożeń, które z nich wynikają. Na tym etapie proponuję też wskazać fragmenty aplikacji, dla których należy sprawdzić istnienie typowych błędów.
Zarówno ten etap, jak i kolejne, najwygodniej będzie wykonywać przy pomocy przeglądarki internetowej (np. Firefox z rozszerzeniami: Firebug, Live HTTP Headers, Modify Headers i Edit Cookies) w połączeniu z Burp Suite lub podobnym narzędziem. Szczególnie polecam Burp Proxy, który pozwala modyfikować „w locie” dane przesyłane pomiędzy przeglądarką i serwerem. Po uruchomieniu Burp Suite należy ustawić w przeglądarce proxy localhost:8080, proponuję też przełączyć działanie Burp Proxy na „intercept off” i włączyć przechwytywanie dopiero przy następnych testach.
Podczas przeglądania przez nas testowanej aplikacji Burp Suite będzie na bieżąco aktualizował listę znalezionych podstron/linków, którą później można przejrzeć w zakładce spider->run->”show results”. W połączeniu z danymi uzyskanymi wcześniej z Wfuzz powinniśmy mieć w ten sposób w miarę dobry obraz struktury plików w aplikacji.
W trakcie tego etapu proponuję „przeklikać” aplikację kilkukrotnie, za każdym razem zmieniając nieco ustawienia przeglądarki:
- ze standardowymi ustawieniami
- z wyłączoną obsługą JavaScript
- z wyłączonym nagłówkiem Referer (w rozszerzeniu Modify Headers do Firefoksa reguła „Filter”:”Referer”:”")
Powyższy krok może pomóc w szybkim wykryciu brakującej walidacji po stronie serwera (realizowanej tylko skryptami JavaScript) oraz zabezpieczeń bazujących na adresie strony odsyłającej.
Załóżmy, że testowany serwis zawiera następujący zestaw funkcji (do nich będę się odnosił również w następnych częściach):
- wyświetlenie podstrony o zadanym identyfikatorze
- wyszukiwanie
- rejestracja użytkownika
- logowanie/wylogowanie użytkownika
- mechanizm odzyskiwania zapomnianego hasła
- zmiana hasła, adresu e-mail i innych danych użytkownika, usuwanie konta
- edycja tekstu/HTML (notka w serwisie blogowym, komentarz w sklepie internetowym, itp.)
- upload plików (np. grafiki)
- przesyłanie wiadomości pomiędzy użytkownikami/do obsługi serwisu/na adres e-mail
Za elementy z natury niebezpieczne uznałbym możliwość edycji HTML (persistent XSS, CSRF, phishing), możliwość przesyłania e-maili (spam, phishing), upload plików (kod wykonywalny, persistent XSS, phishing) oraz mechanizm odzyskiwania zapomnianego hasła. Analiza tych funkcji serwisu będzie zatem bardziej złożona – w trakcie testów powinniśmy sprawdzić, jakie zostały wprowadzone zabezpieczenia, ocenić ich skuteczność i ewentualnie zaproponować alternatywne rozwiązania. Pozostałe z dostępnych akcji nie powinny mieć wpływu na bezpieczeństwo, o ile nie zawierają błędu programistycznego – a więc ich testy sprowadzą się do sprawdzenia typowych problemów (reflected XSS, CSRF, SQLI, header injection, path traversal, session fixation, integer overflow, itd.).
Najtrudniejsze do wykrycia są zazwyczaj błędy w logice aplikacji. Ponieważ są one ściśle powiązane z zastosowaniem serwisu, nie można ich znaleźć przy pomocy skanerów i wymagają przygotowania osobnego zestawu testów praktycznie dla każdej funkcji. Do ataków wykorzystujących błędy logiczne zalicza się między innymi parameter tampering i forceful browsing, ale zakres tego typu problemów może być bardzo szeroki. Przykładem może być sytuacja, w której wieloetapowy mechanizm odzyskiwania hasła nie bierze pod uwagę zmian danych użytkowników jakie nastąpiły pomiędzy etapami, w wyniku czego na adres atakującego może być przesłany link do zmiany hasła innego użytkownika.
Przy okazji polowań na błędy w logice serwisu można też spróbować określić, jakie działania użytkownika nie powinny mieć miejsca w określonych sytuacjach, nawet jeśli nie mają wpływu na bezpieczeństwo. Przykład: wykorzystanie przypomnienia hasła w momencie, gdy użytkownik jest zalogowany. Zwykle nie ma powodu, by blokować takie zachowanie (wyjątek: ataki XSS/CSRF), jednak jest ono nieco podejrzane, i w związku z tym można do istniejących mechanizmów ostrzegania dodać alert dla tej sytuacji. Wprowadzenie większej ilości takich punktów kontrolnych może ułatwić odpowiednio wczesne wykrywanie nietypowych (a więc zwykle niechcianych) działań użytkowników – to już oczywiście zadanie dla programistów i administratorów serwisu, ale testerzy mogą mieć ciekawe pomysły, które warto zapisać.
Proponuję wrócić teraz do Burp Suite i zwrócić uwagę na możliwości narzędzi Repeater oraz Intruder. Jednym z elementów testu bezpieczeństwa powinno być sprawdzenie, czy zasoby dostępne wyłącznie dla zalogowanych użytkowników rzeczywiście są chronione. W tym celu wylogujemy się z aplikacji, a następnie w zakladce spider->run->”show results” wybierzemy interesujący nas plik. Po kliknięciu prawym klawiszem wybieramy „send request to repeater”, po czym przechodzimy do podświetlonej na czerwono zakładki. W polu tekstowym widoczne jest żądanie HTTP, które przeglądarka wykonała podczas legalnego dostępu do danej strony. Wybierając przycisk „go” powtórzymy to żądanie, a w dolnym okienku pojawi się odpowiedź serwera, która powinna wskazywać odmowę dostępu do strony (np. komunikat, przekierowanie do strony logowania, formularz logowania).
Burp Intruder przedstawię już w następnej części tego tekstu (na przykładzie próby ataku na parametr określający wybór podstrony serwisu). Trzecia część będzie też zawierać informacje o atakach wykorzystujących upload plików.
Komentarze
Leave a Comment
Widzę, że cykl rozwija się dobrze. Trochę skrótowe potraktowanie tematu, ale jak wiadomo książkę by można napisać na ten temat. Co do BurpProxy – ostatnio przerzuciłem się na WebScarab. Jakoś tak lepiej pasuje do moich potrzeb. Cdn.
WebScarab nie używałem, ale życia bez Burpa sobie nie wyobrażam ;) Dziękuję za Twoje uwagi z poprzedniej notki – myślę że dorzucę je do tekstu, kiedy uda mi się go skończyć i połączyć w jakąś jedną sensowną całość. Btw, zgaduję że na SecureCON będziesz poruszał podobne tematy? Pewnie w tym roku w końcu się tam wybiorę.
Najważniejsze że się dzieje i dzieje się dobrze :} Zapraszamy na securecon mocno gdyż okazji do napicia [^H^H^H^H...] spotkania się razem nigdy nie za wiele :] To co piszemy książkę ? ;]
Tak, wybieram się na securecon. Co do tematów, to zamierzam się skupić na AJAX-ie i mod_security. Jak pisał kanedaaa, będzie przynajmniej okazja coś wypić :)
Kanedaaa:
A wiesz, że z tą książką to nie taki głupi pomysł? Pogadamy przy piwie.
Bardzo przyjemny jest tez Odysseus (Windows).
Do poprzedniego odcinka: przy rekonesansie warto tez „przejechac” serwer NStalkerem (Windows), ktorego okrojona (ale wystarczajaca) wersja jest dostepna online.
PS: Åwietna seria artykulow! :-)
Nic jednak nie zastąpi edukacji użytkowników.