Aplikacje internetowe

Bełdziowe spojrzenie na aplikacje internetowe

Flashowe logowanie

Poniższa notka będzie opisywała dwa zagadnienia, które na blogu nie były jeszcze poruszane. Będą to technologia Flash oraz narzędzie Burp Suit. Flash większości osób kojarzy się wyłącznie z animacjami. Jednakże jakiś czas temu firma Adobe zadbała o developerów tworząc framework Flex. W związku z tym coraz częściej Flash może być spotkany w roli środowiska dla aplikacji RIA. W związku z tym pojawia się konieczność zadbania o bezpieczeństwo owych aplikacji.

W większości kursów na temat tworzenia systemu logowania we Flex’ie możemy spotkać prosty sposób realizujący to działanie. Można go przedstawić w następujący sposób:

Pobierz od użytkownika login oraz hasło.
Wywołaj skrypt przekazując jako parametry podane przez użytkownika dane.
Jeśli w odpowiedzi zwrócone zostanie „0” wyświetl komunikat „Błędne dane”.
W przeciwnym wypadku użytkownik zalogował się prawidłowo.

Powyższy sposób na pierwszy rzut oka wydaje się być sensowny, jednak jeśli uświadomimy sobie, że aplikacja wysyłająca i odbierająca dane znajduje się na komputerze użytkownika sprawa się zaczyna komplikować.

W „klasycznym” modelu dane przesyłane są przez użytkownika na serwer, gdzie w bezpiecznym środowisku są przetwarzane. W przypadku aplikacji działającej na maszynie użytkownika nie ma pewności co do bezpieczeństwa danych zarówno przychodzących od użytkownika jak i od serwera. Mimo że jesteśmy autorami skryptu, który przesyła dane nie mamy pewności, że dane które zostały wysłane przez serwer są tymi samymi, które otrzyma aplikacja. Mogą one zostać po drodze zmienione na przykład przez firewall, który filtruje pewne ciągi znaków. Innym miejscem modyfikacji może być serwer proxy.

Przykład użycia

Stwórzmy prostą aplikację flexową, która będzie przeprowadzała autoryzację użytkownika na podstawie opisanego wyżej schematu.

Zobacz przykład.

Aby zobaczyć kod powyższej aplikacji wystarczy kliknąć na nią prawym przyciskiem myszy, a następnie wybrać View Source.

Jak widać wpisanie danych innych niż „admin”, „admin” skutkuje pojawieniem się komunikatu „Podane dane są nieprawidłowe” tak więc nasza aplikacja działa prawidłowo. Zobaczmy jednak co dzieje się w tle po kliknięciu przycisku „Loguj”.

Burp Suit

Burp Suit jest narzędziem służącym do testowanie bezpieczeństwa aplikacji internetowych. W jego skład wchodzi między innymi Burp Proxy umożliwiający wgląd w dane przesyłane protokołem HTTP(S). Standardowo wyświetlane są tylko dane, które wysyłamy, aby mieć wgląd również w dane odbierane musimy zaznaczyć opcję Intercept if: znajdującą się na zakładce Proxy → Options → Intercept Server Rensponses.

Po wykonaniu powyższej operacji zostaje nam włączenie obsługi serwera proxy w przeglądarce podając jako dane: localhost:8080. Od tej chwili wejście na dowolną stronę będzie skutkowało przesłaniem danych do Burp Proxy, w którym poza wglądem w nie będziemy mogli określić akcję, która ma zostać podjęta – przesłanie żądania dalej, lub też jego porzucenie.

Wróćmy teraz do naszej aplikacji. Po wpisaniu dowolnych danych i kliknięciu przycisku „Loguj” Burp Proxy prezentuje żądanie wysyłane przez aplikację. Wśród dostępnych nagłówków możemy znaleźć adres skryptu służącego do autoryzacji.

GET /login/login.php?login=fsdfsdf&passwd=fsdfsdf HTTP/1.0

Po zaakceptowaniu żądania możemy zobaczyć odpowiedź przesłaną przez serwer.

HTTP/1.1 200 OK
Date: Fri, 19 Jun 2009 13:33:15 GMT
Server: Apache/2.2.11 (Win32) PHP/5.2.8
X-Powered-By: PHP/5.2.8
Content-Length: 1
Connection: close
Content-Type: text/html

0

Jak widać rezultatem wysłanego żądania jest „0” informujące o niepowodzeniu logowania.

Burp Proxy posiada jeszcze jedną ciekawą opcję, o której nie wspomniałem. Umożliwia edycję wysyłanych / odbieranych danych. Tak więc mimo nieudanego logowania możemy zmodyfikować odpowiedź serwera tak, aby aplikacja myślała, że logowanie przebiegło pomyślnie. Zmieniając „0” na „1” i klikając przycisk „forward” aplikacja informuje nas, że zalogowaliśmy się poprawnie.

Rozwiązanie powyższego problemu jest bardzo proste, wystarczy dodać obsługę sesji po stronie serwera. Dzięki temu użytkownik będzie identyfikowany na podstawie wygenerowanego tokena sesji, tak jak ma to miejsce w przypadku „klasycznych” aplikacji.

Tak więc wystarczy zmiana dotychczasowego kodu PHP

echo (string)( $_GET[ 'login' ] == 'admin' && $_GET[ 'passwd' ] == 'admin'  );

na

session_start(  );
	
if( $_SESSION[ 'isUser' ] )
   // do sth
elseif( $_GET[ 'login' ] == 'admin' && $_GET[ 'passwd' ] == 'admin'  )
   echo $_SESSION[ 'isUser' ] = true;

aby nasze logowanie stało się bezpieczniejsze.

Dodatkowo dane dostępne po zalogowaniu nie powinny być na stałe osadzone w aplikacji, ponieważ będzie możliwy dostęp do nich po zdekompilowaniu pliku. Wszystkie dane wymagane logowania powinny pochodzić z serwera i być przesyłane po uprzednim upewnieniu się, że w sesji istnieje informacja o poprawnym zalogowaniu się.


Tagi: , , , ,
Kategoria: Bezpieczeństwo, Flash / Flex, Bezpieczeństwo, Logowanie, Bezpieczeństwo, Narzędzia


Dodaj komentarz