22:52
18/10/2014

Jakiś czas temu opisywaliście przypadek kolizji klucza sesyjnego w serwisie GoldenLine.

Jak pisze jeden z czytelników, to samo przytrafiło mu się ze stroną liveleak.com. I to dwukrotnie.

Pierwszy raz miało to miejsce w wakacje, ale tylko mocno się zdziwiłem, przeskanowałem komputer w poszukiwaniu rootkitow itp… nic nie znalazłem. [Obecnie] mam pełny dostęp do konta, ustawień itp…
http://i.imgur.com/NQFzTz9.jpg

Z tego powodu jeszcze raz warto rozważyć, co może zrobić użytkownik na koncie w waszym serwisie internetowym bez podowania “czegoś co zna” lub “czegoś co ma” (a czego nie będzie znała/miała osoba wchodząca na daną sesję poprzez kolizję klucza).

Przeczytaj także:

Ten wpis pochodzi z naszego linkbloga *ptr, dlatego nie widać go na głównej.
*ptr możesz czytać przez RSS albo przez sidebar po prawej stronie serwisu.

15 komentarzy

Dodaj komentarz
  1. To samo mam na niebezpiecznik.pl. Moge być moderatorem kiedy chcę!

    • to czemu piszesz to w komentarzach?

  2. Jak działają te klucze sesji? Nie ma jakiejś tablicy z nimi na serwerze i algorytmu sprawdzającego, czy taka sesja już nie istnieje (jeśli tak to losuje inną i nie nadaje już istniejącej)?

    • Działają tak, jak ktoś zaimplementuje…

    • No niezbyt. Nie widziałem jeszcze implementacji generowania ID sesji, która sprawdzałaby, czy przypadkiem takie ID nie jest już zajęte (np. w PHP mam wrażenie, że to kwestia API – nie wydaje się wspierać operacji typu “zaalokuj nową sesję”, tylko session backend dostaje już gotowe ID i musi z nim pracować, czyli wczytać, bez metadanej “czy to ma być nowa sesja”, więc i tak nie wie, czy sprawdzać kolizje, czy wręcz przeciwnie – oczekiwać “kolizji”, czyli otwarcia istniejącej sesji).

      Większość implementacji z pewnością przedkłada lekkość (szybka generacja ID bez odwołań blokujących do FS/IO) nad bezpieczeństwo (jeśli klient nie wysłał ID, wygeneruj jedno i sprawdź, czy już nie istniało) [wymagany cytat].

      PHP na przykład używa adresu IP klienta jako elementu wejściowego (seed) do generacji sessionID (ale nie tylko tej jednej danej), co zmniejsza ryzyko kolizji (ponieważ zwiększa entropię), ale go nie eliminuje [ http://stackoverflow.com/questions/18937651/php-session-ids-how-are-they-generated ].

      Stworzenie implementacji sprawdzającej, czy sesja nie koliduje z istniejącymi przy tworzeniu, w zasadzie nie jest złym pomysłem. Należało by jednak pamiętać o sytuacjach typu race condition, żeby wyeliminować zupełnie zagrożenie kolizji. Przydadzą się tutaj blokady na plikach (+ działający Distributed Lock Manager dla systemów klastrowych na sieciowych FS-ach) albo operacje atomicznego zapisu i sprawdzenia unikatowości (SQL UNIQUE index, Redis SETNX itp.).

    • @CluelessKiwi
      Albo użyć memcached i nie martwiś się FS

  3. Problem kolizji sesji w ostatnim czasie zaczął rosnąć w siłę, wygląda na to, że rozwiązanie via Simple PHP Session Handler przestało być bezpieczne, ponieważ kolizję zdarzają się nawet przy relatywnie małej liczbie client request do serwera. Dlatego sadze, że iż dobrym aspektem było by poruszenie tego tematu z ukierunkowaniem na to jak sobie z tym radzić, myślę iż wtedy treści te będą bogatym źródłem inspiracji dla waszych czytelników, jak również dla mnie.

    • “rozwiązanie via Simple PHP Session Handler przestało być bezpieczne, ponieważ kolizję zdarzają się nawet przy relatywnie małej liczbie client request do serwera”

      Wysnuwasz zbyt daleko idące wnioski. Większe prawdopodobieństwo jest, że programiści/administratorzy popełnili błąd jak funkcja skrótu zaczęła nagle generować częste kolizje.

    • częsta generacja kolizji może być także z przyczyny wadliwej seri generatorów liczb losowych w procesorach

    • “częsta generacja kolizji może być także z przyczyny wadliwej seri generatorów liczb losowych w procesorach”

      spisek?

  4. Napisze to samo co w podobnym poscie:
    Jak X lat temu zaczynalem zabawe z aplikacjami webowymi to juz wtedy jako poczatkujacy robilem cos takiego:
    do {
    $session_id = generuj_sid();
    while (sid_istnieje($sess_id));

    bo nie ufalem losowosci swojej funkcji generujacej, ktora robila mniejwiecej md5(random()).
    Tak czy siak, prosty while i obojetne jak dziala generuj_sid() szans na kolizje NIE MA.

    Druga sprawa, ze session ID powinno byc sprzezone z adresem IP celem zabezpieczenia przed session hijacking.
    Komputery stacjonarne zadko zmieniaja IP – nie czesciej niz co 24h (restart routera, itp.) – wiec problemu nie ma. Rozumiem, ze w przypadku app mobilnych bylo by to uciazliwe wiec sie nie czepiam ;)

  5. To samo miało nuplays podczas internetowej premiery płyty (wersja kolekcjonerska, o ile gratisową zawieszkę tak można nazwać). Ludzie płacili za swoje zamówienie złożone na nie swoim koncie i wysyłane na nie swój adres.

  6. Podawanie przez użytkownika jakiś dodatkowych danych jest całkowitym zaprzeczeniem użyteczności. Należy raczej iść w kierunku dodatkowego sprawdzania jak np ip (wiem że niektórzy mają load balancery na łączach ale admini je stawiający są świadomi ograniczeń jakie mogą one nakładać na użytkownika końcowego), ale przecież można jeszcze dołożyć sprawdznie systemu operacyjnego, przeglądarki, etaga. Od biedy czemu nie dokładać do ciasteczka drugiej danej – np zaashowanego timestampa rozpoczęcia sesji (utworzenia session id) i na tej podstawie sprawdzać unikalność? ew wylogować usera jeżeli sesja nie pasuje do ciacha (choć zniszczenie sesji na serwerze spowoduje wylogowanie 2 użytkowników)

  7. To co piszesz jest skrajnie głupie. A hotspoty wymuszające zmianę adresu co godzine? A aero2? Ludzie, nie idźcie tą drogą.

  8. Parę razy mi się kolizja sesji zdarzyła na deviantarcie. Raz przez przypadek, logując się do siebie wszedłem na konto jakiegoś Turka a innym razem jakiegoś Francuza.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.