2015-06-26 13 views
9

Istnieje wiele artykułów omawiających, jakie jest najlepsze miejsce do przechowywania JWT na kliencie. Krótko mówiąc, są one o -Uwierzytelnianie jwt: ciasteczko kontra nagłówek

  • HTTP tylko bezpieczne cookie - nie XSS, ale vulnarable do XSRF

  • żniwna (zapisywane w pamięci lokalnej lub DOM) - Brak XSRF, ale vulnarable do XSS

myślę wymyślić niezwykle zrozumiały rozwiązania tego problemu, ale ponieważ jestem kompletną Noob w bezpieczeństwie nie jestem pewien, czy to naprawdę bystry lub głupie.

Co zrobić, aby podzielić JWT i zapisać jego część w pliku cookie i innej części w nagłówku? Czy byłby nie do złamania?

Powinno to również rozwiązać „wylogowania” problem. - usuwanie części nagłówka stałaby przeglądarka niezdolny do logowania

poważaniem, Eugene.

Odpowiedz

8

JWT musi pozostać razem, w przeciwnym razie weryfikacja podpisu nie będzie działać.

Ochrona przed XSRF jest całkiem prosta, wystarczy jeszcze jeden plik cookie.

Nigdy nie używaj pamięci lokalnej do przechowywania informacji uwierzytelniających, nie ma ona tej samej domeny i reguł pochodzenia, co pliki cookie. Czytaj więcej tutaj:

https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Storage_APIs

Oświadczenie: Pracuję na Stormpath mamy hostowane rozwiązanie zarządzania użytkownikami i spędzamy dużo czasu na bezpieczeństwo. Pisałem dwa blogach gdzie omówię JWTs i front-end logowania:

Token Based Authentication for Single Page Apps (SPAs)

https://stormpath.com/blog/build-secure-user-interfaces-using-jwts/

Nadzieja to pomaga!

+0

Ale dodatkowy plik cookie do ochrony przed XSRF oznacza utrzymywanie sesji po stronie serwera, prawda? Jeśli tak, sklejenie JWT z powrotem jest znacznie prostsze i lżejsze. I znowu, jeśli tylko część JWT jest przechowywana w pamięci lokalnej, czy może mieć jakąkolwiek wartość dla atakującego? – user656449