Learn-json-web-tokens: Vulnérabilités de sécurité

@sarneeh merci d'avoir ouvert ce numéro. ??
Si vous avez le temps de créer une Pull Request, n'hésitez pas ! (_vous avez un accès en écriture à ce référentiel_)

Les problèmes de sécurité applicables aux JWT sont les mêmes que pour les autres schémas de jetons.
Si un utilisateur malveillant est capable d'exécuter une attaque XSS sur le domaine, il pourra acquérir le JWT et l'utiliser pour usurper l'identité de l'utilisateur, quelle que soit la manière dont il est stocké sur le client.
Malicious JS peut lire et divulguer des cookies et localStorage tout aussi facilement.

Nous devons informer les utilisateurs de JWT qu'ils ne protègent pas contre les attaques OWASP et ne sont qu'un moyen _pratique_ de transmettre des revendications/données signées. ??

@nelsonic

Les problèmes de sécurité applicables aux JWT sont les mêmes que pour les autres schémas de jetons.
Si un utilisateur malveillant est capable d'exécuter une attaque XSS sur le domaine, il pourra acquérir le JWT et l'utiliser pour usurper l'identité de l'utilisateur, quelle que soit la manière dont il est stocké sur le client.
Malicious JS peut lire et divulguer des cookies et localStorage tout aussi facilement.

Je suis en partie d'accord. Vous avez quelque chose comme un cookie httpOnly et secure qui empêche un attaquant d'acquérir votre JWT. Mais je suis tout à fait d'accord que si vous êtes ouvert aux attaques XSS, cela ne vous protège de rien car quelqu'un peut faire des choses au nom de l'utilisateur (pas voler le token, mais c'est à dire injecter un script malveillant).

Donc je suppose qu'en fin de compte, peu importe si vous utilisez localStorage ou un cookie - si vous êtes ouvert aux attaques OWASP - vous êtes foutu. Mais si vous êtes protégé contre eux, vous devriez être en sécurité avec les deux méthodes.

J'adorerais préparer des relations publiques, mais je ne suis pas à l'heure en ce moment et je serai libre dans les 1-2 prochains mois. Si quelqu'un ne me dépasse pas, je préparerai des relations publiques 😄

@sarneeh merci d'avoir ouvert ce numéro.
Si vous avez le temps de créer une Pull Request, n'hésitez pas ! (_vous avez un accès en écriture à ce référentiel_)

Les problèmes de sécurité applicables aux JWT sont les mêmes que pour les autres schémas de jetons.
Si un utilisateur malveillant est capable d'exécuter une attaque XSS sur le domaine, il pourra acquérir le JWT et l'utiliser pour usurper l'identité de l'utilisateur, quelle que soit la manière dont il est stocké sur le client.
Malicious JS peut lire et divulguer des cookies et localStorage tout aussi facilement.

Nous devons informer les utilisateurs de JWT qu'ils ne protègent pas contre les attaques OWASP et ne sont qu'un moyen _pratique_ de transmettre des revendications/données signées.

Comme indiqué ci-dessus, le cookie peut avoir l'option httpOnly.
Selon cet article, il n'est vraiment pas sûr d'utiliser localstorage au lieu de httponly cookie

Bien que j'aie l'impression d'avoir clairement indiqué que vous ne devriez jamais stocker d'informations sensibles dans un stockage local dans la section précédente, je ressens le besoin d'appeler spécifiquement les jetons Web JSON (JWT).
Les plus grands contrevenants à la sécurité que je vois aujourd'hui sont ceux d'entre nous qui stockent les JWT (données de session) dans un stockage local. Beaucoup de gens ne réalisent pas que les JWT sont essentiellement la même chose qu'un nom d'utilisateur/mot de passe.
Si un attaquant peut obtenir une copie de votre JWT, il peut faire des demandes au site Web en votre nom et vous ne le saurez jamais. Traitez vos JWT comme vous le feriez avec un numéro de carte de crédit ou un mot de passe : ne les stockez jamais dans un stockage local.