Ai-je besoin d'un jeton CSRF si j'utilise Bearer JWT?
Contexte : Angular est hébergé sur S3 derrière CloudFront, distinct du serveur Express utilisé comme API et presque tous les demandes sont XMLHttpRequests. Toutes les demandes sont envoyées sans cookies (withCredentials = false par défaut) et j'utilise le jeton JWT Bearer pour l'authentification en le prenant des cookies dans angular et en le plaçant dans Authorization header (Cette technique est un peu ce qui est décrit dans page Wiki CSRF ).
Sur le site Express, je n'autorise pas l'en-tête Cookie dans Access-Control-Allow-Headers.
Les cookies ont secure: true flag, et NE SONT PAS httpOnly car j'ai besoin d'y accéder manuellement en angulaire.
J'ai également lu dans cet article moyen que les jetons JSON-Web (JWT)/porteur
est sans aucun doute l'une des meilleures méthodes de prévention de la CSRF
Question 1 : Vais-je ajouter une sécurité supplémentaire si j'ajoute un en-tête X-XSRF-Token à chaque demande et par exemple rendre le mécanisme sans état en vérifiant cette même valeur dans la charge utile JWT? (Je l'ai lu à ce sujet dans ce fil )
Question 2 : Ai-je réellement besoin d'efforts de sécurité supplémentaires contre CSRF en prenant tout ce que j'ai décrit?
Ceci est pertinent mais ne répond pas nécessairement à 100% de votre question:
https://security.stackexchange.com/a/166798/149676
En bref, tant que l'authentification n'est pas automatique (généralement fournie par le navigateur), vous n'avez pas à vous soucier de la protection CSRF. Si votre application joint les informations d'identification via un en-tête Authorization, le navigateur ne peut pas authentifier automatiquement les demandes et CSRF n'est pas possible. Par conséquent, je reformulerais légèrement la citation de votre article: ce n'est pas que les jetons au porteur sont la meilleure défense contre les attaques CSRF, mais simplement que CSRF est un vecteur d'attaque qui attaque spécifiquement les demandes où le navigateur fournit automatiquement l'authentification (généralement les cookies et authentification de base), et donc CSRF n'a pas d'importance si le navigateur ne peut pas vous authentifier.
Vous devez probablement vous assurer et vérifier, côté serveur, que votre application ne retombe pas silencieusement dans la validation des cookies si le jeton Bearer est absent. Je pouvais voir quelque chose comme ça grincer dans une application par accident, et puisque les cookies seront envoyés, que vous le vouliez ou non, cela pourrait entraîner une vulnérabilité CSRF par inadvertance sur une page qui était "supposée" être immunisée contre CSRF.
Par conséquent, je pense que vos deux questions une et deux peuvent recevoir la même réponse. Si vous utilisez uniquement l'authentification via des jetons au porteur et non via des cookies, la vulnérabilité CSRF ne pose aucun problème et aucune étape supplémentaire n'est requise pour la sécurité.
Généralement, CSRF se produit lorsqu'un navigateur ajoute automatiquement des en-têtes (c'est-à-dire: ID de session dans un cookie), puis authentifie la session. Les jetons de support ou d'autres jetons basés sur l'en-tête HTTP qui doivent être ajoutés manuellement vous empêcheraient de CSRF.
Bien sûr, mais en quelque sorte hors sujet, si vous avez une vulnérabilité XSS, un attaquant pourrait toujours accéder à ces jetons, mais cela ne devient pas un bogue CSRF.
Les réponses précédentes sont solides. Je vais sauter ici pour fournir un contexte plus et une petite mise en garde. Il existe de nombreuses façons d'utiliser JWT; la gestion de session en fait partie. Bien qu'il présente quelques inconvénients lorsqu'il s'agit de délais d'attente et d'exigences avancées comme la ré-authentification.
De plus, j'ai vu JWT placé dans Cookies . Comme d'autres l'ont indiqué, la protection CSRF ne vient pas de l'utilisation d'un JWT lui-même. Il vient de le soumettre en tant qu'en-tête Autorisation , en utilisant le porteur [JWT] régime.
Question 1: Vais-je ajouter une sécurité supplémentaire si j'ajoute un en-tête X-XSRF-Token à chaque demande et par exemple rendre le mécanisme sans état en vérifiant cette même valeur dans la charge utile JWT? (J'ai lu à ce sujet dans ce fil)
Si vous le soumettez via XHR en tant qu'en-tête d'autorisation, aucun en-tête X-XSRF-Token supplémentaire n'ajoutera de sécurité "supplémentaire" .
Question 2: Ai-je besoin d'efforts de sécurité supplémentaires contre CSRF en prenant tout ce que j'ai décrit?
Non , votre configuration actuelle est correcte.
Il y a quelque temps, j'ai compilé un guide des techniques d'authentification Web et leurs propriétés de sécurité (il a également ne partie JWT ). Voici la feuille de triche finale décrivant toutes les méthodes sous une forme compacte.
Je pense qu'il est important de mettre en évidence quelque chose concernant les applications de page unique (ou les demandes de tout frontend en général) qui peuvent rendre les protections CSRF inutiles. J'ai pensé au début que cela pouvait être un peu hors sujet ici, mais je reconsidère (voir ma note en bas).
Mon point: peut-être que vous avez un code d'application frontal qui fait automatiquement une demande à une API lors du chargement de l'application à partir d'une URL (l'un des exemples les plus courants est la validation d'une adresse e-mail). Dans ce cas, que vous ayez ou non CSRF est complètement hors de propos. Dès qu'un événement se produit sur votre application frontale sans nécessiter une action utilisateur spécifique, la protection CRSF n'est pas pertinente car un attaquant a un moyen "légitime" d'effectuer une action en vous faisant simplement ouvrir votre application frontale.
Quelques exemples qui me viennent à l'esprit d'actions qui peuvent être effectuées automatiquement du côté frontal
- Authentification (génération de jetons d'accès, etc.)
- Valider un e-mail
- Suivre un lien e-mail pour évaluer automatiquement certains contenus
- (dés) abonnement à des e-mails/newsletters
- télécharger un fichier (si l'application frontale traite préalablement certaines choses avant de transmettre la demande de téléchargement au serveur)
- Rejoindre un projet, un groupe
- Validation d'un code référent
Certains de ces cas d'utilisation (comme la validation d'un e-mail) peuvent ne pas nécessiter d'authentification et être relativement inoffensifs, mais d'autres (comme rejoindre un groupe) n'ont de sens que lorsque vous êtes authentifié, ce qui signifie que vous avez un moyen d'effectuer automatiquement une demande authentifiée contre une API. C'est peut-être moins dangereux si l'utilisateur a des commentaires directs sur ce qui s'est passé (en supposant que votre frontend donne vos commentaires à vos utilisateurs), et s'ils peuvent annuler ces opérations, mais cela reste un vecteur d'attaque.
Nous pensons souvent à "CSRF" comme un moyen de se protéger contre les demandes envoyées directement à une application serveur ou à une API. Corrigez-moi si je me trompe, mais la définition semble englober toute attaque où la personne malveillante n'est pas en mesure de voir le résultat de ce qui s'est passé, y compris l'utilisation du code d'application frontale.