GWT: Przechowywanie identyfikatora sesji w pliku cookie, a następnie co?

Question

Aktualnie tworzę stronę za pomocą GWT, będąc hostowanym na AppEngine. Robię to z własnymi loginami, które robię (wiem, że Google dostarcza coś z GWT, ale potrzebuję mojego własnego systemu logowania) i od pewnego czasu próbuję rozgryźć sesje. Znalazłem kilka samouczków i jedna z witryn, które czytałem, to: http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ

Na stronie znajduje się sekcja "Jak zapamiętać logowanie". Wiem, jak uzyskać identyfikator sesji i zapisać go na kliencie w pliku cookie za pośrednictwem wywołania RPC. Czego nie rozumiem, w końcu po około dniu, użytkownik wraca i mam otrzymać identyfikator sesji z pliku cookie i wysłać go z powrotem na serwer. Co powinienem zrobić na serwerze, aby bezpiecznie ocenić, czy ID sesji jest nadal legalne i wyciągnąć wszystkie niezbędne informacje o użytkowniku?

Dodatkowe pytania: 1. Co zmieniłoby ID sesji? 2. Co jeśli użytkownik był na laptopie, a użytkownik poszedł gdzie indziej. Czy nadal będzie mógł być bezpiecznie zalogowany bez konieczności ponownego wpisywania swojego loginu i hasła?

Dzięki!

~ Scott

Answer 1

Aby zapamiętać loginy musisz bezpiecznie wygenerować unikalny identyfikator sesji. Zwykle umieszczany jest w pliku cookie. Polecam używanie struktury, która wykonuje pliki cookie sesji. Nieprawidłowe działanie może sprawić, że twoja strona stanie się szeroko otwarta na nadużycia. Rzeczy do rozważenia to:

• Czy musisz martwić się o kradzież plików cookie. Adres IP użytkownika powinien być zakodowany w identyfikatorze sesji lub powiązany z identyfikatorem sesji. Sprawdź adres IP przy każdym dostępie do strony.
• Upewnij się, że twoje loginy są w zaszyfrowanych sesjach. W przeciwnym razie ujawniasz dane uwierzytelniające w postaci zwykłego tekstu w sieci.
• Jak długo powinny trwać sesje. Powinny upłynąć po określonym czasie. Może to być kilka godzin lub dni.
• Pamiętaj, że powinienem mieć inną funkcjonalność na innym pliku cookie. Musi zawierać coś, co może posłużyć do identyfikacji użytkownika. W zależności od wymagań bezpieczeństwa może być potrzebna wartość zaszyfrowana. Ten plik cookie może mieć dłuższy limit czasu.

Odpowiedzi na dodatkowe pytania są następujące.

1. Nic po stronie klienta nie może zmienić identyfikatora sesji. Identyfikator sesji powinien być odnawiany przy każdym logowaniu.
2. W zależności od tego, jak bezpieczny jest identyfikator sesji, może być konieczne zalogowanie. Bezpieczne ciasteczka sesyjne często kodują adres IP, aby zapobiec kradzieży plików cookie. Jeśli tak, użytkownik laptopa musiałby się ponownie zalogować.

Answer 2

Podobne pytanie: question on GWT, Cookies and webpage directing.
Jedna ważna rzecz, o której powinieneś pamiętać: nie polegaj wyłącznie na plikach cookie - prześlij identyfikator sesji/token w treści żądania i porównaj ją z wartością cookie po stronie serwera. Zapobiegnie to atakom XSRF. To jest coś, o co powinieneś się martwić.

Zasady postępowania z identyfikatorami sesji zależą od tego, jak poważnie traktujesz bezpieczeństwo w aplikacji i jaki to rodzaj aplikacji.Na przykład możesz logować się przy użyciu tego samego tokena w Gmailu z różnych adresów IP - domyślam się, że zezwalają na to, ponieważ często zmieniają się IP użytkownika w trakcie sesji. Dodano jednak funkcję, która pozwala sprawdzić, z których adresów IP ostatnio się logował użytkownik. I nie zapomnij o użytkownikach z dynamicznymi adresami IP (dość duża liczba) - jeśli będziesz śledzić tokeny i adresy IP, zasadniczo uniemożliwisz tym użytkownikom zalogowanie między sesjami.

Co mam zrobić na serwerze aby prawidłowo ocenić, czy ID sesji jest nadal legalne i podciągnąć wszystkie niezbędne informacje na temat użytkownik?

Powinieneś śledzić pary sesji/identyfikatorów sesji w twoim DB.

Co zmieniłoby ID sesji?

Albo wygasa, albo użytkownik próbuje się zalogować przy pomocy tokena, który nie jest związany z ich adresem IP. Możesz również dodać własne reguły - takie jak liczba loginów itp. Dla dodatkowego bezpieczeństwa możesz wygenerować nowy identyfikator sesji/tokena na każdym nowym logowaniu/sesji (użytkownik uwierzytelnia się starym tokenem, serwer sprawdza, czy jest ważny i odsyła użytkownikowi nowy token, którego powinien używać od teraz).