Paweł Goleń, blog

Protokół HTTP sam w sobie jest bezstanowy. Interakcja klienta z serwerem jest prosta, klient wysyła żądanie, serwer przygotowuje odpowiedź i... tyle. Co prawda są różnego rodzaju rozszerzenia/udogodnienia wynikające głównie z przyczyn wydajnościowych, nie zmienia to jednak istoty rzeczy.

Z drugiej strony aplikacje internetowe są jak najbardziej stanowe. Przykładowo użytkownik rozpoczyna interakcję z aplikacją jako użytkownik nieuwierzytelniony, następnie uwierzytelnia się, wykonuje określone operacje (lub ich sekwencję), później wylogowuje się. W jakiś sposób jego poszczególne akcje muszą być powiązane ze sobą. Pojawia się tu pojęcie sesji użytkownika, a metodą wiązania konkretnego żądania HTTP z sesją są zwykle identyfikatory sesji przekazywane w cookies. Oznacza to w praktyce, że w celu "wejścia" w sesję użytkownika, należy przejąć cookie z identyfikatorem sesji (i dlatego częstym przykładem dowodzenia wykonalności ataku XSS jest fragment skryptu alert(document.cookie).

Cookie bywają chronione przed tego typu atakiem. Przykładem takiej ochrony jest na przykład flaga httpOnly. Jej ustawienie dla cookie powoduje, że skrypty nie mają do niego dostępu. Można dodać do tego flagę Secure, która powoduje, że cookie przesyłane jest tylko bezpiecznym połączeniem (SSL). Nie zmienia to jednak faktu, że cookie jest wysyłane automatycznie przy żądaniu do serwera (z ograniczeniami odnośnie typu połączenia i ścieżki).

Skoro nie można przejąć sesji, to może wykonać jakieś operacje w kontekście innego użytkownika? Wbrew pozorom jest to bardzo proste. Najłatwiejsza metoda to wstawienie "obrazka", który w rzeczywistości jest odwołaniem do jakiejś funkcji w aplikacji.

Przykładowo w NK za odrzucenie zaproszenia odpowiada prosty URL: http://nasza-klasa.pl/reject/[id]?r=1 Mogę więc na jakiejś stronie osadzić "sfałszowany" obrazek, którego źródłem jest ten właśnie URL. W chwili wyświetlenia "sfałszowanej" strony moja przeglądarka wyśle odpowiednie żądanie dołączając do tego odpowiednie cookie (jeśli akurat będę zalogowany do NK) i zaproszenie zostanie odrzucone.

Najłatwiejsza metoda, by przeciwdziałać tego typu atakom, to dodawanie do każdego żądania pewnego unikalnego tokenu. Oczywiście należy sprawdzać, czy otrzymany token jest "oczekiwany" i przypadkiem nie został wykorzystany już wcześniej.

Interesujące może być prześledzenie tego, jak zmieniły się nawyki przeciętnego "klikacza" przez lata. Podejrzewam, że dzisiaj jest normą posiadanie otwartych w przeglądarce wielu zakładek i przeglądanie (prawie) jednoczesne wielu stron. Prawdopodobieństwo, że w jednej zakładce otwarta będzie "interesująca" strona (np. jakaś bankowość), a w drugiej użytkownik otworzy "złą" stronę, jest duże. Problem w tym, że cookies są dzielone między wszystkimi tabami w przeglądarce.

W tym miejscu przyznam, że nie wiem, jak sprawa wygląda w Chrome oraz jak będzie wyglądać w IE8. W IE7, Firefox 3 i Opera 9 nie ma jednak pod tym względem żadnej separacji między tabami. W przypadku Firefox 3 nie ma również separacji między oknami (nie ma różnicy, czy "zła strona" zostanie otwarta w notym tabie, czy w nowym oknie).

W przypadku IE7 pewna różnica jest. Wybranie File - New Window powoduje uruchomienie kolejnego okna w tym samym procesie przeglądarki, czyli pod rozważanym względem jest to tożsame z otwarciem nowego taba. Nowe okno można również otworzyć uruchamiając kolejny raz przeglądarkę. Spowoduje to utworzenie nowego procesu, dla którego cookie z wcześniej otwartego/otwartych okien nie będzie dostępne. Mowa oczywiście tylko o cookie sesyjnych (tych, które nie są zapisywane na dysk). Cookie o dłuższym okresie ważności zostaną oczywiście przez nowy proces wczytane z dysku.

Innymi słowy - taby zwiększają prawdopodobieństwo udanego ataku typu CSRF ponieważ nie zapewniają separacji między sobą (w tym wypadku - współdzielą cookies), jednocześnie "przyzwyczajając" użytkowników do pracy z wieloma otwartymi jednocześnie stronami.