HARD CORE SECURITY LAB

Zapraszam do zapoznania się z interesującym opracowaniem autorstwa Wojtka Sznapki, traktującym o atakach typu session fixation. Autor na co dzień pracuje w zaprzyjaźnionej z HARD CORE SECURITY LAB gliwickiej firmie XSolve, która to zajmuje się przede wszystkim tworzeniem zwinnych i skrojonych na miarę aplikacji dedykowanych. Co ważne, XSolve potrafi dzielić się wiedzą i własnymi doświadczeniami, czego efektem jest projekt XLab, ale również to, że możemy się dziś zapoznać z poniższym interesującym artykułem.

Sesje w aplikacjach internetowych

Ze względu na fakt, że protokół HTTP jest bezstanowy, wyszła potrzeba, aby identyfikować wywołania tego samego użytkownika i przechowywać zmienne pomiędzy nimi. Tym mechanizmem są sesje. Każda sesja jest identyfikowana ciągiem znaków (domyślnie jest to losowy, 32 znakowy łańcuch), który jest przechowywany w ciasteczku (cookies) lub przekazywany przez URL. Identyfikator sesji jest unikalny dla użytkownika, a więc osoba, która w nieuprawniony sposób wejdzie w jego posiadanie, praktycznie wykrada tożsamość danego użytkownika w danej aplikacji (portalu, sklepie internetowym, blogu, portalu społecznościowym).

Zagrożenia

Jako że, ciasteczka, czyli mechanizm zapisu informacji w przeglądarce użytkownika przez aplikację internetową, są mechanizmem względnie bezpiecznym, projektanci aplikacji zawsze powinni wybierać ten sposób przechowywania identyfikatora sesji. Przekazywanie SESSID (session id) w url’u wystawia aplikację na zagrożenie atakiem session fixation.

Szkodnik, który przejmie naszą sesje, może poczynić spore spustoszenie w naszej przestrzeni systemu, od publikacji kompromitujących treści, poprzez dostęp do prywatnych danych, historii naszej działalności (np. zakupów), poprzez nawet wykonanie w naszym imieniu dowolnej transakcji. Zagrożenia jakie za tym idą, są różne, ze względu na różne specyfiki aplikacji webowych.

Co to jest session fixation?

Session fixation polega na podsunięciu użytkownikowi linku do atakowanej aplikacji ze spreparowanym identyfikatorem sesji, który jest znany atakującemu. Jak to działa w praktyce? Przygotowujemy url w postaci:

• http://moja.aplikacja?sekcja=profil&SESSID=1234abcd1234abcd1234abcd1234abcd

i sugerujemy użytkownikowi jego kliknięcie, posyłając np. emailem lub linkując go pod jakieś zdjęcie. Użytkownik wchodzi do atakowanej aplikacji. Jako, że korzysta z nowej sesji, loguje się do systemu i wykonuje jakieś operacje. Atakujący wchodzi do aplikacji z tego samego linku i ma do dyspozycji zalogowane konto, dzięki czemu może wykonać dowolne operacje w imieniu skompromitowanego użytkownika. Ze względu na specyfikę tego ataku, często w sieci stosuje się inne określenie: session riding, ponieważ w pewnym sensie jeździmy na czyjejś sesji.

Jak się bronić z punktu widzenia programisty?

Metoda jest prosta i domyślnie włączona w nowych wersjach PHP. Nigdy nie powinno się używać identyfikatora sesji przekazywanego przez URL! Aby to osiągnąć, można użyć następujących ustawień PHP (w pliku php.ini):

session.use_trans_sid = 0

session.use_cookies = 1

session.use_only_cookies = 1

Poza tym, powinniśmy regenerować id sesji przed logowaniami (metodą session_regenerate_id). Ostatnią rzeczą, która ochroni nas też przed innymi atakami, polegającymi na wyłudzeniu tożsamości, jest ponowne sprawdzenie hasła przed krytycznymi operacjami, takimi jak zmiana hasła, zmiana danych profilowych, usunięcie konta, czy dokonanie jakiejś sporej płatności. Tę metodę stosuje wiele znanych serwisów internetowych.

Jak się bronić z punktu widzenia użytkownika aplikacji?

Jako, że nie wiemy, czy aplikacja z której korzystamy jest podatna na tego typu ataki, powinniśmy zawsze ostrożnie korzystać z linków, które dostajemy z nieznanych źródeł. Jeśli jesteśmy zalogowani do portalu X, a za chwilę dostaniemy podejrzanie długi link, po wejściu na który znowu jesteśmy proszeni o hasło, to znaczy, że coś nie gra i należy się dwa razy zastanowić przed ponownym wykonaniem logowania.

[Od Redakcji]
Jak więc widzimy, ostrożne obchodzenie się z odnośnikami niewiadomego pochodzenia jest zawsze dobrym pomysłem. Szczególną ostrożność należy zaś zachować w sytuacji, gdy nieznany odnośnik zaprowadzi nas do jakiegokolwiek (nawet znajomo wyglądającego) interfejsu logowania. W takim wypadku pod żadnym pozorem nie należy podawać własnych poświadczeń.