Get best of the week

Informationen zum Speichern von JWT-Token in Browsern


Der offene JWT-Standard wurde 2015 offiziell veröffentlicht ( rfc7519 ) und verspricht interessante Funktionen und breite Perspektiven. Die ordnungsgemäße Speicherung des Zugriffstokens ist für den Aufbau eines Autorisierungs- und Authentifizierungssystems im modernen Web von entscheidender Bedeutung, da Websites, die mit SPA-Technologie erstellt wurden, immer beliebter werden.

Eine falsche Aufbewahrung von Token führt zu deren Diebstahl und Wiederverwendung durch Angreifer.

Wo also lagern?


Berücksichtigen Sie die wichtigsten Optionen zum Speichern des JWT-Zugriffstokens in einem Browser:

  1. Lokaler Speicher / Sitzungsspeicher - Die Methode ist nicht sicher und anfällig für Angriffe wie XSS, insbesondere wenn Sie Skripts von CDNs von Drittanbietern verbinden (das Hinzufügen des Integritätsattributs kann keine 100% ige Sicherheit garantieren) oder wenn Sie nicht sicher sind, ob die Skripts, mit denen Sie eine Verbindung herstellen, nicht in der Lage sind, Daten zusammenzuführen Speicher zur Seite. Wenn lokaler Speicher zwischen Registerkarten verfügbar ist, ist Sitzungsspeicher nur auf einer Registerkarte verfügbar, und das Öffnen einer Site auf einer neuen Registerkarte führt nur zu einer neuen Runde von Zugriffstoken / Autorisierung.
  2. , , fetch . – .
  3. Cookies. «» cookie sessions. Access cookie CSRF. XSS . CSRF Cookie SameSite Strict– , , credentials, CSRF .
    – Access JS httpOnly, Secure .

    Ein wichtiger Punkt ist, ein Cookie nur für die Domänen- / Pfad-API zu setzen, damit Anforderungen an die öffentliche Statik keinen Overhead im Header enthalten.

Was ist das Ergebnis?


Cookies sind bei korrekter Verwendung die geeignete und sicherste Lösung zum Speichern des JWT Access-Tokens und müssen die folgenden Regeln befolgen:

  1. Wird für die Domänen- / Pfad-API installiert, um Overhead beim Anfordern statischer Dateien (öffentliche Images / Styles / JS-Dateien) zu vermeiden.
  2. Haben Sie ein sicheres Flag (nur zur Übertragung über https).
  3. Haben Sie das httpOnly- Flag (für den unzugänglichen Zugriff über JavaScript).
  4. Das SameSite Attribut muss Strenge gegen CSRF - Angriffe zu schützen, verbieten die Übertragung von Cookies , wenn der Übergang zu Ihrer API nicht aus der Domäne Satz im Cookie war.

Auf der Serverseite sollte es auch konfiguriert werden:

  1. Content-Security-Policy - Beschränken Sie vertrauenswürdige Domänen, um mögliche XSS-Angriffe zu verhindern
  2. X-Frame-Options- Header zum Schutz vor Clickjacking-Angriffen.
  3. X-XSS-Schutz - Erzwingen Sie den integrierten Schutzmechanismus des Browsers vor XSS-Angriffen.
  4. X-Content-Type-Options - zum Schutz vor dem Ersetzen von MIME-Typen.

Die Einhaltung dieser Maßnahmen in Verbindung mit der häufigen Rotation von Zugriffs- / Aktualisierungstoken sollte dazu beitragen, ein hohes Maß an Sicherheit auf der Site zu gewährleisten.

Einschränkungen


Trotz der Tatsache, dass das SameSite- Attribut in vielen gängigen Browsern unterstützt wird , gibt es auch Browser, die es nicht oder nur teilweise unterstützen (Hallo IE und Safari für Mac). In diesen Fällen benötigen Sie einen Fallback für CSRF-Token. In diesem Fall muss neben Anforderungen an die API auch das CSRF-Token übertragen werden. Das richtige CSRF-Token muss vom Server unter Berücksichtigung des Fingerabdrucks des Benutzers generiert werden, um die Wahrscheinlichkeit seiner Ersetzung zu minimieren.

More articles:


All Articles