Lekcja 21: Przykład - phishing na formatce logowania z wykorzystaniem XSS
UWAGA: przykład ten ostatecznie służy do demonstracji dwóch różnych problemów:
- phishingu na formatce logowania,
- session fixation,
Zadanie I: Phishing na formatce logowania
Pod adresem http://bootcamp.threats.pl/lesson21/ znajduje się przykładowa formatka logowania do aplikacji. Formatka ta podatna jest na cross-site scripting w jednym z parametrów jej wywołania (wskazówka: jakie parametry przekazywane są w trakcie uwierzytelnienia użytkownika?). Zadanie polega na skonstruowaniu takiego kodu JavaScript, by dane uwierzytelniające zostały wysłane pod inny adres:
- poprzez modyfikację adresu, na który wysyłany jest formularz,
- w inny sposób,
Przykład ten jest dostępny również po SSL. Można sprawdzić, czy wykorzystanie SSL w jakikolwiek sposób utrudnia lub uniemożliwia wykonanie takiego ataku.
Ponieważ certyfikat SSL, który wykorzystuje domena bootcamp.threats.pl nie jest do końca prawidłowy (mówiąc oględnie), wskazane są dodatkowe przygotowania. Patrz niżej.
Phishing: przygotowanie
UWAGA: Certyfikat w tym przykładzie nie jest zaufany, można ten problem jednak obejść w następujący sposób:
- puścić ruch przeglądarki przez Fiddler,
- dodać do zaufanych urzędów certyfikacji certyfikat "root" generowany przez Fiddlera,
Po prawidłowym wykonaniu tych operacji przeglądarki korzystające z systemowego mechanizmu obsługi certyfikatów (Internet Explorer, Chrome) potraktują certyfikaty generowane przez Fiddlera dla stron pobieranych po HTTPS jako zaufane.
Zadanie II: Session Fixation
Celem drugiego zadania jest ustawienie użytkownikowi znanej sobie wartości cookie PHPSESSID. Jeżeli sesja użytkownika będzie posiadała znany identyfikator, atakujący będzie w stanie ją przejąc po uwierzytelnieniu.
W tym przypadku zobrazowane są dwa problemy:
- session adoption,
- session fixation,
Pierwsze pojęcie opisuje sytuację, w której aplikacja (lub środowisko, w którym ona działa) akceptuje i wykorzystuje jako identyfikator sesji wartość, która nie została przez nią wygenerowana. W normalnym przypadku powinno ustawianie identyfikatora sesji powinno wyglądać tak:
- czy żądanie zawiera aktywny identyfikator sesji,
- jeśli nie zawiera: wygeneruj nowy identyfikator,
- jeśli zawiera: użyj identyfikatora,
W przypadku session adoption jeśli otrzymany od użytkownika identyfikator sesji nie jest aktywny, aplikacja (środowisko) tworzy nową sesję i przypisuje jej identyfikator otrzymany od użytkownika.
Session fixation polega na ustawieniu identyfikatora sesji przez atakującego. Może, ale nie musi, być powiązane z session adoption. Nawet jeśli środowisko akceptuje wyłącznie identyfikatory wygenerowane przez siebie, atak ten nadal jest możliwy. W tym scenariuszu atakujący może po prostu stworzyć nową sesję, a następnie próbować zmusić ofiarę do użycia właśnie tego, znanego atakującemu, identyfikatora.
W jaki sposób atakujący może zmusić użytkownika do użycia konkretnego identyfikatora sesji? Ma na to wiele sposobów. Jeden z nich należy wykorzystać w tym przykładzie.
Zobacz też: