2012-01-04 16 views
13

Czytałem, że struktura gry rozwiązuje problem związany z naprawą sesji przez mieszanie identyfikatora sesji z kluczem aplikacji, ale czy zapewnia on dowolny mechanizm zapobiegający przejmowaniu sesji lub czy jest on pozostawiony do implementatora?Czy grasz! framework ma wbudowany mechanizm zapobiegający przechwytywaniu sesji?

+0

Do tej pory mam odpowiedź "tak" i "nie", więc istnieją tu oczywiście sprzeczne informacje. – marchaos

+0

Nadal czuję, że to pytanie jest bez odpowiedzi, ale niestety muszę przyznać nagrodę w każdym przypadku. Jeśli ktoś mógłby odpowiedzieć definitywną odpowiedzią, byłoby wspaniale. – marchaos

Odpowiedz

3

Dokumentacja odtwarzania ma dobrą sekcję poświęconą zabezpieczeniom, więc zamiast powielać, tutaj jest link - http://www.playframework.org/documentation/1.2.4/security.

Obejmuje

  • XSS
  • SQL Injection
  • bezpieczeństwo Sesja
  • Cross Site Request Fałszerstwo

Niektóre trzeba realizować siebie, inni nie.

Twoje szczegółowe pytanie dotyczące przechwytywania sesji jest automatyczne.

Sesja jest hashem kluczy/wartości, podpisana, ale nie zaszyfrowana. To oznacza, że ​​dopóki twój sekret jest bezpieczny, nie jest możliwe, aby trzecia strona utworzyła sesje.

+0

Dzięki za odpowiedź. Naprawdę nie widzę, jak zawężanie kluczowych wartości i podpisywanie go kluczem aplikacji zapobiega kradzieży plików cookie i ich używaniu. Być może czegoś brakuje? – marchaos

+0

ponieważ, jeśli ktoś nim manipuluje, nie zna skrótu, więc wartość skrótu staje się nieważna, a Play wie, że sesja została unieważniona. – Codemwnci

+2

Co zrobić, jeśli się z tym nie manipulują. Jeśli powącham plik cookie i nie zmieniam żadnych wartości w nim zawartych, to z pewnością, ponieważ wartość skrótu jest nadal ważna (zakładając, że jest ona przechowywana w pliku cookie), mogę uwierzytelnić za pomocą wartości. – marchaos

3

Nie, nie ma wbudowanych w celu uniemożliwienia porwania sesji, gdy tylko będzie można przechwycić plik cookie sesji (przez wąchanie/człowiek w środku). Istnieje kilka sposobów, aby utrudnić, np:

  • HTTPS tylko
  • ustawienia application.session.httpOnly w application.conf

One approache aby utrudnić jest: - przechowaj plik ip/user-agent/rozdzielczość/inne elementy lub skrót tego również w sesji. W kontrolerze sprawdź, czy użytkownik, który uzyskuje dostęp do witryny, nadal odtwarza ten sam skrót ... jedyny prawdziwy problem jest z osobami, które używają proxy, które np zmienia IP w locie z powodu klastrowania.

mały trick można spróbować użyć: (działa tylko w najnowszych przeglądarkach) Kiedy użytkownik loguje się, przechowywać kilka rzeczy w HTML5 pamięci lokalnej. Zmodyfikuj połączenia Ajax, aby dostarczyć te informacje z lokalnego magazynu. Jeśli brakuje informacji/jest ona nieważna, możesz unieważnić całą sesję. Musisz jednak upewnić się, że kontrole zostaną zastosowane tylko wobec żądań z przeglądarek HTML5.

mam nadzieję, że to trochę pomaga.

+0

Przechowywanie ip i klienta użytkownika jest złym pomysłem. Zobacz http://stackoverflow.com/questions/969330/including-user-ip-addr-for-hash-cookie-value-bad-idea – marchaos

+0

jesteś adresami linków, które powiedziałem z "jedynym rzeczywistym problemem jest z ludzie używający proxy, który np. zmienia IP w locie z powodu klastrowania. " Nie ma nic przeciwko przechowywaniu hasza agenta użytkownika, ponieważ jeśli to zmieni się podczas sesji, sesja została przejęta. Wszystko zależy od tego, ile energii chcesz w to włożyć i czy naprawdę jest tego warte. Zmiana/usunięcie danych wrażliwych powinna zawsze być możliwa tylko za pośrednictwem protokołu SSL i podania hasła. –

Powiązane problemy