Paweł Goleń, blog

Dziś krótki przykład, który pokazuje dlaczego zmiana identyfikatora sesji po uwierzytelnieniu jest dobrą praktyką.

Część pierwsza – dlaczego należy zmieniać identyfikator sesji

Zmiana identyfikatora sesji po uwierzytelnieniu (albo jeszcze lepiej – przy zmianie stanu sesji, na przykład z nieuwierzytelniony na uwierzytelniony, ale również z uwierzytelniony na nieuwierzytelniony) jest dobrą praktyką. Jeśli tego się nie robi (i przy spełnieniu kilku dodatkowych warunków), pojawia się session hijacking wynikające z session fixation. Najłatwiej (choć nie jest to jedyna technika) wykorzystać to przesyłając URL postaci http://adres.do.aplikacji/sciezka/plik;**sessiondid=AAABBBCCCDDD**_ (lub inny, zależnie od technologii w jakiej wykonana jest aplikacja). Jeśli serwer aplikacyjny akceptuje identyfikatory sesji przekazywane w ten sposób, a ofiara z linku skorzysta, znając identyfikator sesji można ją przejąć. Znajomość identyfikatora sesji nie dałaby atakującemu nic (no, z dokładnością do konstrukcji aplikacji), jeśli identyfikator ten zmieniłby się po uwierzytelnieniu.

Część druga – przypadek szczególny: wyłączone cookies

Jeśli identyfikator sesji przekazywany jest w cookie i nie jest akceptowany identyfikator przesłany w URL, wykorzystanie podatności polegającej na braku zmiany identyfikatora sesji jest trudne. Jak jednak zachowa się aplikacja, jeśli przeglądarka nie akceptuje cookies? Znów – zależnie od wykorzystanej technologii (lub nawet w zależności od konfiguracji)...

Może być na przykład tak:

• identyfikator sesji przekazywany jest w URL,
• ustawiany jest nowy cookie,
• przeglądarka nie akceptuje nowego cookie, nadal przekazuje stary identyfikator sesji w URL,
• aplikacja uznaje, że klient nie obsługuje cookies i akceptuje identyfikator przekazany w URL,
• aplikacja nie zmienia identyfikatora sesji po uwierzytelnieniu,
• (...) wiadomo co...

Powyższy scenariusz został sprawdzony empirycznie w przypadku jednej aplikacji. Oznacza to, że aplikacja ta jest podatna na session fixation , co normalnie jest ZŁE. Z drugiej strony by dało się to wykorzystać w prosty sposób, konieczna jest niestandardowa zmiana konfiguracji przeglądarki użytkownika, należy uwzględnić więc, że podatność dotyczy tylko pewnej grupy użytkowników.

Jak duża jest “pewna” grupa...

Szczerze mówiąc – nie wiem. Może okazać się, że ta zmiana wprowadzana jest przez większy odsetek ludzi, niż można się tego spodziewać. Wszak (uwaga – ironia) cookies to straszne zagrożenie dla prywatności, zawierają wirusy i trojany, powodują, że krowy przestają dawać mleko, a kury nieść jaja (koniec ironii), a przynajmniej takie wrażenie można odnieść po niektórych artykułach w “fachowej” prasie, albo po lekturze materiałów marketingowych wszelakich “zaawansowanych narzędzi do usuwania malware/spyware i innych takich”. Tak, cookies w pewnym stopniu są zagrożeniem dla prywatności, ale nie można popadać w przesadę... Swoją drogą akceptowanie cookies tylko na czas życia sesji (przeglądarki), oraz blokowanie “third party cookies” skutecznie utrudnia (utrudnia, nie uniemożliwia) to śledzenie.

Oryginał tego wpisu dostępny jest pod adresem Dlaczego należy zmienić identyfikator sesji po uwierzytelnieniu

Autor: Paweł Goleń