Heim  >  Artikel  >  Web-Frontend  >  Web-Sicherheit: localStorage vs. Cookie zum Speichern von Token

Web-Sicherheit: localStorage vs. Cookie zum Speichern von Token

WBOY
WBOYOriginal
2024-08-28 06:08:02298Durchsuche

Web Security: localStorage vs cookie for storing tokens

Die sicherste Vorgehensweise besteht darin, den Token im Anwendungsstatus zu speichern. Es ist jedoch wichtig zu beachten, dass das Token zurückgesetzt wird, wenn der Benutzer die Anwendung aktualisiert. Dies kann zum Verlust des Authentifizierungsstatus des Benutzers führen.

Deshalb müssen Token in einem Cookie oder localStorage/sessionStorage gespeichert werden.

localStorage VS-Cookie zum Speichern von Token

Das Speichern von Authentifizierungstokens in localStorage kann ein Sicherheitsrisiko darstellen, insbesondere im Zusammenhang mit Cross-Site Scripting (XSS)-Schwachstellen, die möglicherweise zum Token-Diebstahl durch böswillige Akteure führen können.

Die Option zum Speichern von Tokens in Cookies, konfiguriert mit dem HttpOnly-Attribut, kann die Sicherheit erhöhen, da sie für clientseitiges JavaScript nicht zugänglich sind. In unserer Beispiel-App verwenden wir js-cookie für die Cookie-Verwaltung, wobei wir davon ausgehen, dass die echte API das HttpOnly-Attribut für erhöhte Sicherheit erzwingt und die Anwendung keinen Zugriff auf das Cookie von der Client-Seite hat.

Implementierung mit React und Typescript

Um eine sichere Token-Verwaltung in einer React TypeScript-Anwendung mit js-cookie zu implementieren, bei der die echte API das HttpOnly-Attribut erzwingen würde, können Sie die folgenden Schritte ausführen:

1. Das Setup verstehen

HttpOnly-Cookies: Diese Cookies werden vom Server gesetzt und sind nicht über JavaScript zugänglich, wodurch sie sicherer gegen XSS-Angriffe sind.
Annahme: Der Server übernimmt das Setzen und Verwalten von HttpOnly-Cookies. Ihr clientseitiger Code konzentriert sich auf die Verarbeitung von Tokens über API-Antworten und -Anfragen.

2. TypeScript-Setup reagieren

Stellen Sie zunächst sicher, dass Sie js-cookie installiert haben:

npm install js-cookie

3. Einrichten der Token-Verwaltung

import React, { createContext, useContext, useEffect, useState } from 'react';
import Cookies from 'js-cookie';

interface AuthContextType {
  token: string | null;
  login: (token: string) => void;
  logout: () => void;
}

const AuthContext = createContext<AuthContextType | undefined>(undefined);

export const useAuth = () => {
  const context = useContext(AuthContext);
  if (!context) {
    throw new Error('useAuth must be used within an AuthProvider');
  }
  return context;
};

export const AuthProvider: React.FC<{ children: React.ReactNode }> = ({ children }) => {
  const [token, setToken] = useState<string | null>(null);

  // Assuming the token is returned from a server and set as an HttpOnly cookie
  useEffect(() => {
    const fetchTokenFromServer = async () => {
      // Example API call to authenticate and retrieve token (token management handled by server)
      try {
        const response = await fetch('/api/authenticate', {
          method: 'POST',
          credentials: 'include', // This sends the HttpOnly cookie to the server
        });

        if (response.ok) {
          setToken(await response.text()); // Assume token returned in response body for simplicity
        }
      } catch (error) {
        console.error('Error fetching token:', error);
      }
    };

    fetchTokenFromServer();
  }, []);

  const login = (token: string) => {
    // If your server returns the token via a non-HttpOnly cookie or body, store it as needed
    Cookies.set('token', token); // Only use this if the token is not HttpOnly
    setToken(token);
  };

  const logout = () => {
    Cookies.remove('token');
    setToken(null);
  };

  return (
    <AuthContext.Provider value={{ token, login, logout }}>
      {children}
    </AuthContext.Provider>
  );
};

4. Verwendung des Authentifizierungskontexts in Komponenten

import React from 'react';
import { useAuth } from './AuthProvider';

const Dashboard: React.FC = () => {
  const { token, logout } = useAuth();

  if (!token) {
    return <p>You are not logged in.</p>;
  }

  return (
    <div>
      <h1>Dashboard</h1>
      <p>Your token is: {token}</p>
      <button onClick={logout}>Logout</button>
    </div>
  );
};

export default Dashboard;

5. Umgang mit HttpOnly-Cookies

Da der clientseitige Code nicht direkt auf HttpOnly-Cookies zugreifen kann, muss der Server diese Cookies verarbeiten. In einem realen Szenario:

Anmeldung: Wenn sich der Benutzer anmeldet, setzt der Server das HttpOnly-Cookie und der Client verwaltet es nicht direkt.
API-Anfragen: Alle Anfragen, die eine Authentifizierung erfordern, sollten die Anmeldeinformationen enthalten: Option „include“, um das HttpOnly-Cookie zu senden.

6. Serverseitige Implementierung

Stellen Sie sicher, dass Ihre serverseitige API das Token als HttpOnly-Cookie festlegt. Zum Beispiel auf einem Express.js-Server:

res.cookie('token', token, { httpOnly: true, secure: true, sameSite: 'Strict' });

7. Sichern Sie Ihre Bewerbung

  • Verwenden Sie in der Produktion immer https, um sicherzustellen, dass Cookies sicher übertragen werden.

  • Erwägen Sie die Einstellung „secure: true“ in Ihren Cookies, um sicherzustellen, dass sie nur über HTTPS gesendet werden.

  • Verwenden Sie SameSite=Strict oder Lax, um CSRF-Angriffe zu verhindern.

Vielen Dank fürs Lesen! Wenn Sie diesen Artikel hilfreich fanden, geben Sie ihm bitte einen Daumen nach oben. Wenn Sie Fragen haben oder weitere Erläuterungen zu einem der besprochenen Themen benötigen, können Sie sich gerne an mich wenden. Ich bin hier, um Ihnen zu helfen und würde mich freuen, von Ihnen zu hören! Sie finden mich auf Twitter oder LinkedIn. Ich freue mich darauf, mit Ihnen in Kontakt zu treten!.

Das obige ist der detaillierte Inhalt vonWeb-Sicherheit: localStorage vs. Cookie zum Speichern von Token. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn