Trzecim sposobem poznania cennego identyfikatora sesji jest jego wykradnięcie. W pewnych warunkach do kradzieży identyfikatora można wykorzystać podatność przeglądarek (np. Internet Explorer do wersji 5.1 włącznie) lub serwerów aplikacji. Przykładowo, serwer PHP w wersjach od 4.0 do 4.1.1 zapisywał identyfikator sesji jako nazwę pliku w katalogu/tmp na serwerze. W rezultacie identyfikator mógł być wykradziony przez dowolnego użytkownika posiadającego dostęp do serwera. Najbardziej realny scenariusz kradzieży zakłada wykorzystanie podatności w samej aplikacji WWW . Poniżej opiszę dwa najbardziej rozpowszechnione tego typu ataki na sesje użytkownika za pośrednictwem podatnej aplikacji: cross-site scripting i session fixation. Oba są możliwe w wyniku błędów popełnionych przez projektantów i programistów.

Cross-site scripting

Cross-site scripting (XSS) jest metodą ataku polegającą na możliwości wpłynięcia na kod generowanej przez aplikację strony HTML i włączenia do niego fragmentów wrogiego kodu JavaScript lub ogólnie - kodu skryptowego wykonywanego po stronie przeglądarki. Weźmy pod uwagę fragment aplikacji - przeszukiwarkę, która pokazuje rezultaty przeszukiwania w ten sposób, że wyświetla również komunikat: "Wyniki wyszukiwania dla zapytania wyszukiwane słowo". Skrypt wyszukujący jest wywoływany przez URL: http: //serwer/szukaj?slowo=wyszukiwane_słowo . Jeżeli do parametru "slowo" wstawimy ciąg znaków zawierający kod JavaScript (<script>wrogi kod</script>), wrogi kod JavaScript zostanie umieszczony w kodzie HTML wygenerowanej przez przeszukiwarkę strony HTML w miejscu "Wyniki wyszukiwania dla zapytania..."

Mamy więc sytuację, w której wynikiem użycia odpowiednio zmanipulowanego adresu URL jest wygenerowanie przez aplikację strony zawierającej wrogi kod JavaScript, który następnie uruchomi się w przeglądarce. To właśnie jest istota ataku cross-site scripting. Taki zabieg świetnie nadaje się do wykradania identyfikatora sesji, ponieważ wrogi kod JavaScript jest wykonywany w kontekście aplikacji, ma więc dostęp do jej danych cookie.

Scenariusz kradzieży identyfikatora polega zwykle na skłonieniu użytkownika aplikacji do użycia spreparowanego adresu URL. Po kliknięciu na URL, aplikacja generuje stronę HTML zawierającą wrogi kod JavaScript. Kod ten wykonuje się w przeglądarce ofiary. Wrogi kod JavaScript odczytuje zawartość cookie, w tym identyfikator sesji, i wysyła ją do atakującego. Będąc w posiadaniu aktywnego identyfikatora sesji, włamywacz może "porwać" sesję jej prawowitego użytkownika i wykonywać operacje na serwerze w jego imieniu. Brzmi to dość skomplikowanie, jednak metoda ta jest dość dobrze opisana w literaturze, a atak jest stosunkowo prosty do przeprowadzenia i nie wymaga zaawansowanej wiedzy.

Warunkami powodzenia kradzieży identyfikatora sesji są: (1) istnienie podatności w aplikacji, (2) skłonienie użytkownika aplikacji do użycia URL skonstruowanego przez intruza (wykorzystanie socjotechnik), (3) w momencie ataku aplikacyjna sesja użytkownika powinna być aktywna. Warunki te wskazują także na potencjalne metody obrony przed atakami cross-site scripting.

Aby uchronić się przed atakiem, konieczne jest szczegółowe sprawdzanie wszystkich danych przekazywanych z przeglądarki, a w szczególności uniemożliwienie wstawiania tagów typu <script>. Kolejne zabezpieczenie to krótki czas życia sesji, po którym jest ona przerywana, albo też okresowe regenerowanie identyfikatora sesji. Wcale nie mniej ważne jest jednak edukowanie użytkowników, by byli czujni i nie dali się manipulować. Niektóre banki ostrzegają już na swoich stronach przed otwieraniem wiadomości e-mail rzekomo pochodzących od banku.

Session fixation

Session fixation to druga, bardzo "elegancka" metoda poznawania identyfikatora sesji. Jej istota polega na tym, że zamiast wykradać identyfikator od ofiary, atakujący zmusza ją do użycia wygenerowanej przez niego sesji. Atak przebiega następująco: (1) atakujący wchodzi na stronę aplikacji i otrzymuje identyfikator sesji - większość aplikacji nadaje identyfikator jeszcze przed uwierzytelnieniem; (2) atakujący nakłania ofiarę do użycia wygenerowanej sesji (socjotechnika); (3) ofiara uwierzytelnia się w aplikacji, dzięki czemu atakujący, znając identyfikator sesji (w końcu sam go utworzył), może go użyć do przejęcia sesji.

Najbardziej kłopotliwy jest krok 2, w którym atakujący musi skłonić ofiarę do użycia narzuconego identyfikatora sesji. W praktyce jest to stosunkowo łatwe, ale głównie dla aplikacji, które akceptują identyfikatory sesjiprzesyłane w adresie URL. Wtedy wystarczy, że atakujący skonstruuje URL w postaci: http ://serwer/index?SESSIONID=12345 i skłoni ofiarę do jej użycia. Większość współczesnych serwerów aplikacyjnych używa mechanizmu cookie do przesyłania identyfikatora sesji, jednak w konfiguracji standardowej akceptuje również identyfikator przesłany w URL, a więc powyższy scenariusz jest możliwy.

Wymuszenie na ofierze użycia identyfikatora, który musi być przesłany w cookie, jest również możliwe, ale trudniejsze. Taki atak wymaga podejścia "kombinowanego", np. przy wykorzystaniu innych podatności w przeglądarkach lub aplikacji (np. opisanego wcześniej ataku cross-site scripting).

Warunkami zastosowania metody session fixation są: (1) używanie przez aplikacje tego samego identyfikatora sesji przed i po uwierzytelnieniu użytkownika; (2) akceptowanie przez aplikację identyfikatora sesji przesyłanego w URL (nie jest to warunek konieczny, ale znacznie zwiększa szanse powodzenia ataku) oraz (3) skłonienie użytkownika aplikacji do użycia adresu URL skonstruowanego przez intruza.

Podobnie jak w przypadku cross-site scripting, warunki wykonania ataku wskazują na potencjalne kroki zapobiegające wykonaniu ataków typu session fixation. Przede wszystkim identyfikator sesji należy tworzyć dopiero po uwierzytelnieniu lub alternatywnie - regenerować identyfikator sesji po uwierzytelnieniu (generalnie po każdej zmianie poziomu uprawnień). Wskazane jest również wymuszanie przez serwer przesyłania identyfikatora sesji wyłącznie poprzez pliki cookie. Ważne jest także edukowanie użytkowników (jak wyżej).

Podsumowanie

Jak widać, właściwe zarządzanie sesją użytkownika ma kluczowe znaczenie dla bezpieczeństwa danych przetwarzanych przez aplikacje udostępniane za pośrednictwem serwerów WWW. Ponieważ wykorzystywany w takich rozwiązaniach protokół HTTP nie był tworzony z myślą o sesjach aplikacyjnych, lecz udostępnianiu dokumentów, bezpieczeństwo komunikacji zasadza się na zabezpieczeniu możliwości zdobycia przez niepowołane osoby identyfikatora sesji. Warto o tym pamiętać, negocjując umowę na dostarczenie aplikacji WWW.