2011-12-19 15 views
9

Problem mam, które nie mogą być rozwiązywalne, przedstawia się następująco:Zabezpieczanie Cookies Sesje

Mam klienta, który jest duża organizacja 1,500+ użytkowników w 7-8 różnych miejscach. Aplikacja jest aplikacją PHP zbudowaną na platformie Kohana v3.0. Organizacja znajduje się za serwerem filtrującym proxy na poziomie ISP. Każda lokalizacja ma jeden główny publiczny adres IP, który prowadzi przez serwer proxy do sieci. Każdy użytkownik ma stację roboczą Mac lub Windows wydaną przez pracodawcę.

To, czego się doświadczają, zdaje się być kolizjami plików cookie. Przykład: Jeden użytkownik loguje się na stacji roboczej, a następnie inny użytkownik loguje się z tej samej lokalizacji, z innej stacji roboczej, z tym samym systemem operacyjnym i typem przeglądarki. Drugi użytkownik otrzymuje aktywną sesję pierwszego użytkownika, otrzymując nowo wygenerowany plik cookie (token), który pasuje do pierwszego użytkownika. Wygląda na to, że jest to powiązane tylko z ciasteczką "authautologin" (ustawioną, gdy pole wyboru "zapamiętaj mnie" jest włączone na ekranie logowania), ale zachowuję moje opcje otwarte na buforowanie z serwera proxy (nie mogę udowodnić, że proxy wciąż buforuje).

Z powodu konfiguracji sieci, serwer widzi setki użytkowników logujących się z tego samego adresu IP z tym samym klientem użytkownika. Moja początkowa myśl jest taka, że ​​sposób, w jaki Kohana v3 generuje ciasteczka, które są unikalne dla przeglądarki (agenta użytkownika), nie jest wystarczająco unikalny dla tej aplikacji świata rzeczywistego.

Czy ktoś kiedykolwiek doświadczył czegoś takiego? A jakie byłyby właściwe działania, które można by podjąć w tworzeniu plików cookie i sesji? Czy zarządzanie plikami cookie i aktywne sesje w bazie danych byłyby lepsze?

  • Kohana Moduły: galaretki uwierzytelniania, galaretki, a uwierzytelniania

  • serwera: Apache/2.2.9 (Debian) mod_fastcgi/2.4.6 mod_jk/1.2.26 PHP/5.2.6-1 + lenny8 z Suhosin łaty mod_ssl/2.2.9 OpenSSL/0.9.8g

  • znane przeglądarki IE 8 & 9 Firefox (OS i Win) i Safari (OS)

+0

+1: Ostrożnie zadane pytanie - z dostępnymi szczegółami. Dobra robota. –

+0

Zgadzam się, ale czy to nie problem z serwerem proxy, który dotyczyłby każdej usługi korzystającej z pliku cookie automatycznego logowania? –

+0

@Pekka, która była moją myślą/frustracją w ostatnim tygodniu. Następnie, po zapytaniu ich własnego personelu IT, dowiedziałem się, że celem filtru proxy było blokowanie stron takich jak GMail, Facebook, Twitter itd. Tak więc jestem przekonany, że nie mają dostępu do stron poza sieć, w której się logują. Ta aplikacja może być bardzo dobrym rozwiązaniem, ponieważ może otrzymać plik cookie do automatycznego logowania poza siecią. – ixasilent

Odpowiedz

2

To tylko pomysł, ale istnieje/kiedyś (w zależności od wersji Debiana i PHP) błąd z sesjami PHP.Co proponuję spróbować:

  1. Sprawdź this link - to nie może być związane z problemem, ale warto spróbować
  2. przełącznik do sterownika bazy danych - dałbym 90% szans, że będzie to naprawić wszystko
  3. test na innym serwerze następnie Debian - to może nie być łatwe do osiągnięcia, choć
+0

Nie sądzę, że link ma zastosowanie, ale należycie zanotowany, aby móc z niego skorzystać w przyszłości. Aplikacja korzysta z MySQL PDO za pośrednictwem modułów Baza danych i galaretki Kohana 3.0. Czy są jakieś inne sterowniki? Istnieje około 15 innych stron, które są identyczne (- zawartość bazy danych) na tym serwerze dla innych klientów, którzy nie zgłaszają tego problemu, więc jestem prawie pewien, że ma to związek z tworzeniem sieci i potrzebą dokładnego dostroić generację plików cookie dla tej jednej witryny. Dobry link! Założę to na zakładkę, ponieważ może rozwiązać problem z limitem czasu sesji z wiki, które było na moim wstecznym urządzeniu przez miesiąc. – ixasilent

+0

Mam na myśli sterownik bazy danych przełącznika sesji, nie rezygnuj z PDO/Jelly, jeśli tak myślisz;) – matino

+0

jesteś prawo przechowywania sesji w bazie danych naprawia to. Szczerze mówiąc nie jestem zadowolony z tego rozwiązania, ale na razie spodoba mu się jako hack. Oczywiście, kiedy tysiące użytkowników ponownie zaczyna korzystać z aplikacji, a ja wyglądam jak głupiec ... Wrócę! Dla bezpieczeństwa przepisuję metodę "klasy kohana_cookie", aby była kompatybilna z RFC 2109. To przynajmniej odpowiedzialna rzecz do zrobienia. Dzięki! – ixasilent

2

wow Ów paskudna luka, dobry połów!

Zdecydowanie najlepszym sposobem generowania plików cookie w PHP jest umożliwienie PHP zrobienia tego: session_start(). I to wszystko! Jeśli generujesz własny plik cookie, to naprawdę gdzieś go zawiodłeś. Teraz możesz korzystać z globalnej wersji $_SESSION[]. Najlepiej jest wywołać session_start() we wspólnym pliku nagłówkowym, zanim uzyskasz dostęp do $ _SESSION w swojej aplikacji.

Prawdopodobnie są inne problemy, które należy wziąć pod uwagę, takie jak owasp a9, csrf i flagi plików cookie: HTTP_Only, a także "bezpieczna" flaga (wymuszająca użycie pliku cookie przez https).

+0

@Rock dzięki! Przeszukałem kod kilka razy i mogę sprawdzić, czy tak, używam PHP do zarządzania sesjami (session_start(), session_name(), session_set_cookie_params(), session_destroy(), etc ...). Ale tylko dlatego, że o tym wspomniałeś, znów będę kopał, sprawdzałem i dawałem kredyt tam, gdzie robi się kredyt, kiedy przychodzę po powietrze. Jest to witryna SSL i ustawiono flagi bezpieczne i HTTP_ONLY. – ixasilent

+0

Sorry @Rook nie oznaczało, że chcesz tam podać swoje imię. – ixasilent

+0

@ixasilent Nigdy nie powinieneś ustawiać wartości cookie. Myślę, że polegasz na klasie kohana_cookie, aby zidentyfikować użytkownika. Jest to użycie setcookie(), która jest zła. – rook

0

nie jestem pewien, czy ja zrozumiałem, ale ... zrozumiałem, że prośba jest tak:

użytkownik (stacja robocza) ==> proxy() ==> internet ==> strona firmy (i odpowiedź w odwrotnym kierunku).

Sprawdź, czy proxy ustawia "HTTP_X_FORWARDED_FOR" (w zmiennej superglobalnej $ _SERVER). Może to być jedyny sposób określenia adresu IP stacji roboczej użytkownika. Jeśli tak, skończysz.

+0

Zamknij, ale ponieważ serwer proxy służy również jako dostawca usług internetowych, nie ma HTTP_X_FORWARDED_FOR. – ixasilent