"Autorisation: porteur" dans l'en-tête de la demande corrigera-t-il les attaques CSRF?
J'ai lu sur la correction des attaques CSRF. D'après certaines recherches, je comprends que la recherche d'un en-tête non standard empêcherait les attaques CSRF puisque le navigateur n'enverra pas automatiquement de tels en-têtes.
Je supposais donc de recommander d'utiliser Autorisation: porteur jetons pour l'application ASP que je teste actuellement. Comme cette valeur d'en-tête ne sera pas envoyée par le navigateur lui-même , Je suppose que cette approche résoudrait le problème CSRF. Mais j'ai remarqué une question de débordement de pile qui m'a un peu dérouté. La réponse recommande toujours d'utiliser les jetons CSRF.
Donc, fondamentalement, j'ai deux questions.
- Cette approche fonctionnerait-elle réellement pour empêcher les attaques CSRF?
- Je sais que si je suis vulnérable aux attaques XSS, mes cookies peuvent être lus et les jetons du porteur peuvent être volés. Mais le XSS injecté peut-il créer l'en-tête Authorization: Bearer et ajouter la valeur volée du cookie?
Cette approche fonctionnerait-elle réellement pour empêcher les attaques CSRF?
Oui. Un attaquant ne peut pas obliger un navigateur à envoyer une demande incluant l'en-tête d'autorisation avec le jeton de porteur correct. C'est pour deux raisons:
- L'attaquant ne peut pas définir l'en-tête d'authentification.
- L'attaquant ne connaît pas la valeur correcte du jeton, il ne sait donc pas sur quoi le définir.
Cependant, cela peut être sensible aux modifications de votre application. Par exemple, si quelqu'un décide un jour de changer le système d'authentification en quelque chose basé sur des cookies, il se peut qu'il ne réalise pas qu'il désactive votre protection CSRF en faisant cela.
De plus, dans le cas où la valeur d'en-tête requise est prévisible, une stratégie CORS qui permet de définir cet en-tête pourrait causer des problèmes.
Quant à la question liée SO, je ne suis pas sûr de comprendre la réponse acceptée. Mais si vous regardez la deuxième réponse , votre situation est de type # 2 et ne tapez pas # 1.
Je sais que si je suis vulnérable aux attaques XSS, mes cookies peuvent être lus et les jetons du porteur peuvent être volés. Mais le XSS injecté peut-il créer l'en-tête Authorization: Bearer et ajouter la valeur volée du cookie?
Oui, vous pouvez le faire si vous pouvez injecter du code.
Si vous avez une vulnérabilité XSS, cela permettra à l'attaquant de contourner toute protection CSRF que vous avez mise en place. Ainsi, les préoccupations concernant XSS ne peuvent pas vraiment être utilisées pour favoriser une forme de protection CSRF par rapport à une autre - face à XSS, elles sont toutes nulles.
Une légère différence ici est que votre jeton ne peut pas être marqué comme HTTP uniquement, car vous devez y accéder depuis JS pour le mettre dans l'en-tête. Par conséquent, un attaquant XSS peut le voler puis envoyer facilement des requêtes depuis son propre ordinateur. Si le jeton d'authentification est uniquement HTTP, l'attaquant doit obliger le code injecté à envoyer les requêtes, ce qui est un peu compliqué mais pas impossible.
Cela peut fonctionner, mais XSS compromettra complètement la session.
L'intention des atténuations CSRF est de limiter la portée de qui peut soumettre des données du navigateur d'un utilisateur au serveur et provoquer un incident. Les attaques CSRF fonctionnent en s'appuyant sur les propriétés spéciales des navigateurs Web, car elles incluent généralement des cookies dans toutes les demandes et l'attaquant il suffit que le navigateur envoie une demande à l'URL cible. Vous atténuez cela en faisant en sorte que la demande inclue des données qui ne font pas partie de la demande normalement envoyées par le navigateur; par exemple. un en-tête ou un champ de formulaire personnalisé, injecté par JavaScript.
Un jeton au porteur dans l'en-tête Autorisation nécessite nécessairement d'être ajouté par JavaScript car le navigateur ne l'inclura jamais (sauf NTLM/Nego/etc, mais c'est un autre sujet). Cela correspond donc assez bien à l'exigence énoncée ci-dessus.
Le hic est que tout JavaScript exécuté sur cette page peut faire exactement la même chose que votre code en ajoutant l'en-tête car il n'y a pas de limites de sécurité ici. Cela signifie que vous êtes arrosé par toute forme de XSS qui permet l'exécution de code arbitraire. Et en fait, cela vous place dans une position plus faible car ils peuvent simplement voler votre jeton et faire ce qu'ils veulent avec en dehors des limites d'un navigateur, alors qu'un cookie protégé ne peut pas être volé car il n'est pas accessible par JavaScript.
Donc ... vous êtes en sécurité si vous pouvez empêcher complètement XSS, mais c'est une tâche difficile dans les meilleures circonstances. Cela dit, l'ajout d'un cookie dans le mélange n'aide pas nécessairement, car XSS peut générer des demandes qui ajoutent le jeton, et le navigateur inclura toujours volontiers le cookie.