W kontekście JWTs, Stormpath napisał dość pomocny artykuł opisujący możliwe sposoby ich przechowywania i zalety (dis-)odnoszące się do każdej metody.

Zawiera również krótki przegląd ataków XSS i CSRF oraz sposób ich zwalczania.

Załączyłem kilka krótkich fragmentów artykułu poniżej, na wypadek, gdyby ich artykuł został wyłączony / ich strona poszła w dół.

Local Storage

Problemy:

Web Storage (localStorage / sessionStorage) jest dostępna przez JavaScript w tej samej domenie. Oznacza to, że każdy JavaScript uruchomiony w Twojej witrynie będzie miał dostęp do pamięci internetowej i z tego powodu może być podatny na ataki Cross-Site scripting (XSS). XSS w skrócie to rodzaj luki, w której atakujący może wstrzyknąć JavaScript, który będzie działał na twojej stronie. Podstawowe ataki XSS próbują wstrzyknąć JavaScript przez wejścia formularza, gdzie atakujący umieszcza alert ('you are Hacked'); do formularza, aby sprawdzić, czy jest uruchamiany przez przeglądarkę i może być przeglądany przez innych użytkowników.

Profilaktyka:

Aby zapobiec XSS, powszechną odpowiedzią jest ucieczka i kodowanie wszystkich niezaufanych danych. Ale to daleki od całej historii. W 2015 roku nowoczesne aplikacje internetowe używają JavaScript hostowanego na CDN lub zewnętrznej infrastrukturze. Nowoczesne aplikacje internetowe obejmują biblioteki JavaScript innych firm do testowania A / B, analizy lejka/rynku i reklam. Używamy menedżerów pakietów, takich jak Bower, aby importować Kod innych ludzi do naszego aplikacje.

Co, jeśli tylko jeden ze skryptów, których używasz, jest zagrożony? Złośliwy JavaScript może być osadzony na stronie, a Web Storage jest / align = "left" / Tego typu ataki XSS mogą uzyskać pamięć www wszystkich który odwiedza Twoją witrynę, bez ich wiedzy. Prawdopodobnie dlatego kilka organizacji radzi nie przechowywać niczego wartości lub zaufania wszelkie informacje w pamięci internetowej. Obejmuje to identyfikatory sesji i żetony.

Jako mechanizm przechowywania, magazyn internetowy nie egzekwuje żadnych zabezpieczeń standardy podczas transferu. Kto czyta Web Storage i korzysta z niego musi dokładają należytej staranności, aby zapewnić, że zawsze wysyłają JWT przez HTTPS i nigdy HTTP.

Ciasteczka

Problemy:

Pliki cookie, używane z flagą HttpOnly cookie, nie są dostępne przez JavaScript i są odporne na XSS. Można również ustawić bezpieczną flagę pliku cookie, aby zagwarantować, że plik cookie jest wysyłany tylko przez HTTPS. Jest to jeden z głównych powody, dla których pliki cookie były wykorzystywane w przeszłości do przechowywania tokenów lub danych sesji. Współcześni Programiści wahają się, czy używać plików cookie, ponieważ tradycyjnie wymagali przechowywania danych na serwerze, łamiąc w ten sposób najlepsze praktyki. Pliki cookie jako mechanizm przechowywania nie wymagają przechowywania stanu na serwerze, jeśli przechowujesz JWT w pliku cookie. Dzieje się tak dlatego, że JWT hermetyzuje wszystko, czego serwer potrzebuje do obsługi żądania.

Jednak Pliki cookie są podatne na inny rodzaj ataku: cross-site request forgery (CSRF). Atak CSRF to rodzaj ataku dzieje się tak, gdy złośliwa witryna internetowa, E-mail lub blog powodują, że użytkownik przeglądarka internetowa do wykonania niechcianej akcji na zaufanej stronie, na której użytkownik jest obecnie uwierzytelniony. Jest to wyzysk tego, jak przeglądarka obsługuje pliki cookie. Plik cookie można wysyłać tylko do domen w co jest dozwolone. Domyślnie jest to domena, która pierwotnie Ustaw ciasteczko. Plik cookie zostanie wysłany do wniosek niezależnie od czy jesteś na galaxies.com lub hahagonnahackyou.com.

Profilaktyka:

Nowoczesne przeglądarki obsługują SameSite znacznik , oprócz HttpOnly i Secure. Celem tej flagi jest zapobieganie przesyłaniu plików cookie w żądaniach między stronami, zapobiegając wielu rodzajom ataków CSRF.

W przypadku przeglądarek, które nie obsługują SameSite, CSRF można zapobiec za pomocą zsynchronizowanych wzorców tokenów. To Dźwięki skomplikowane, ale wszystkie nowoczesne frameworki internetowe mają wsparcie dla to.

Na przykład, AngularJS ma rozwiązanie, aby sprawdzić, czy plik cookie jest dostępne tylko dla Twojej domeny. Prosto z AngularJS docs:

Podczas wykonywania żądań XHR, usługa $ http odczytuje token z cookie (domyślnie XSRF-TOKEN) i ustawia go jako nagłówek HTTP (X-XSRF-TOKEN). Ponieważ tylko JavaScript, który działa w Twojej domenie może przeczytaj plik cookie, Twój serwer może być pewien, że XHR przyszedł od JavaScript uruchomiony w Twojej domenie. Możesz zrobić tę ochronę CSRF bezpaństwowiec poprzez włączenie xsrfToken twierdzenia JWT:

{
  "iss": "http://galaxies.com",
  "exp": 1300819380,
  "scopes": ["explorer", "solar-harvester", "seller"],
  "sub": "[email protected]",
  "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}

Wykorzystanie ochrony CSRF web app Framework sprawia, że pliki cookie są rock solidny do przechowywania JWT. CSRF można również częściowo zapobiec poprzez sprawdzanie nagłówka Referer HTTP i Origin z interfejsu API. CSRF ataki będą miały nagłówki Referer i Origin, które nie są powiązane z Twoje podanie.

Pełny artykuł można znaleźć proszę.: https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

Mają również pomocny artykuł o tym, jak najlepiej zaprojektować i wdrożyć JWTs, w odniesieniu do struktury samego tokena: https://stormpath.com/blog/jwt-the-right-way/

Z localStorage, aplikacje internetowe mogą przechowywać dane lokalnie w przeglądarce użytkownika. Przed HTML5 dane aplikacji musiały być przechowywane w plikach cookie, zawartych w każdym zapytaniu serwera. Duże ilości danych mogą być przechowywane lokalnie, bez wpływu na wydajność witryny. Chociaż localStorage jest bardziej nowoczesny, istnieją pewne plusy i minusy obu technik.

Ciasteczka

Plusy

• Legacy support (it ' s been around forever)
• dane trwałe
• wygaśnięcie daty

Cons

• każda domena przechowuje wszystkie swoje pliki cookie w jednym ciągu, który może sprawić, że parsowanie danych trudne
• Dane nie są szyfrowane, co staje się problemem, ponieważ... ... choć niewielkie rozmiary, pliki cookie są wysyłane z każdym żądaniem HTTP o ograniczonym rozmiarze (4KB)
SQL injection może być wykonywane z pliku cookie

Local storage

Plusy

• Obsługa większości nowoczesnych przeglądarek
• trwałe DANE, które są przechowywane bezpośrednio w przeglądarce
• reguły tego samego pochodzenia mają zastosowanie do danych przechowywanych lokalnie
• nie jest wysyłane z każdym żądaniem HTTP
• ~ 5MB pamięci na domenę (czyli 5120kb)

Cons

• Nie obsługiwane przez nic wcześniej: IE 8, Firefox 3.5, Safari 4, Chrome 4, Opera 10.5, iOS 2.0, Android 2.0
• Jeśli serwer potrzebuje przechowywanych informacji o kliencie, celowo masz wysłać.

localStorage użycie jest prawie identyczne z sesyjnym. Oni mają dość dokładne metody, więc przejście z sesji na localStorage jest naprawdę dziecinnie proste. Jeśli jednak przechowywane dane są naprawdę kluczowe dla Twojej aplikacji, prawdopodobnie użyjesz plików cookie jako kopii zapasowej na wypadek, gdyby localStorage nie było dostępne. Jeśli chcesz sprawdzić obsługę przeglądarki dla localStorage, Wystarczy uruchomić ten prosty skrypt:

/* 
* function body that test if storage is available
* returns true if localStorage is available and false if it's not
*/
function lsTest(){
    var test = 'test';
    try {
        localStorage.setItem(test, test);
        localStorage.removeItem(test);
        return true;
    } catch(e) {
        return false;
    }
}

/* 
* execute Test and run our custom script 
*/
if(lsTest()) {
    // window.sessionStorage.setItem(name, 1); // session and storage methods are very similar
    window.localStorage.setItem(name, 1);
    console.log('localStorage where used'); // log
} else {
    document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC";
    console.log('Cookie where used'); // log
}

"wartości localStorage Na bezpiecznych stronach (SSL) są izolowane" jak ktoś zauważył należy pamiętać, że localStorage nie będzie dostępne, jeśli przełączasz się z zabezpieczonego protokołu "http" na "https", gdzie plik cookie nadal będzie dostępny. Jest to dość ważne dla pamiętaj, czy pracujesz z bezpiecznymi protokołami.

Ciasteczka :

1. wprowadzony przed HTML5.
2. ma datę ważności.
3. wyczyszczone przez JS lub przez wyczyszczenie danych przeglądania przeglądarki lub po dacie wygaśnięcia.
4. zostanie wysłana do serwera za każde żądanie.
Pojemność 4KB.
5. tylko ciągi mogą być przechowywane w ciasteczkach.
6. istnieją dwa rodzaje plików cookie: trwałe i sesyjne.

Local Storage:

1. wprowadzony z HTML5.
2. nie ma data ważności.
3. wyczyszczone przez JS lub przez wyczyszczenie danych przeglądania przeglądarki.
4. możesz wybrać, kiedy dane mają zostać wysłane na serwer.
5. pojemność wynosi 5MB.
6. Dane są przechowywane bezterminowo i muszą być ciągiem znaków.
7. mają tylko jeden typ.

Warto również wspomnieć, że localStorage nie może być używany, gdy użytkownicy przeglądają w trybie" prywatnym " w niektórych wersjach mobilnego Safari.

Cytat z MDN ( https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage):

Uwaga: począwszy od iOS 5.1, Safari Mobile przechowuje dane localStorage w folderu cache, który podlega sporadycznemu czyszczeniu, w zachowanie systemu operacyjnego, zazwyczaj jeśli miejsce jest krótkie. Safari Mobile ' s Private Tryb przeglądania również uniemożliwia pisanie do localStorage całkowicie.

Cóż, szybkość lokalnej pamięci zależy w dużej mierze od przeglądarki, z której korzysta klient, a także od systemu operacyjnego. Chrome lub Safari na komputerze mac mogą być znacznie szybsze niż Firefox na komputerze PC, szczególnie w przypadku nowszych interfejsów API. Jak zawsze jednak testowanie jest twoim przyjacielem (nie mogłem znaleźć żadnych benchmarków).

Naprawdę nie widzę wielkiej różnicy w cookie vs local storage. Powinieneś również bardziej martwić się problemami ze zgodnością: nie wszystkie przeglądarki zaczęły nawet obsługiwać nowe interfejsy API HTML5, więc pliki cookie będą najlepszym rozwiązaniem dla szybkości i kompatybilności.

Local storage może przechowywać do 5 MB danych offline, podczas gdy session może również przechowywać do 5 mb danych. Ale Pliki cookie mogą przechowywać tylko 4kb danych w formacie tekstowym.

Dane lokalne i sesyjne w formacie JSON, dzięki czemu są łatwe do przetworzenia. Ale dane cookies są w formacie string.