Est-il nécessaire d'utiliser la protection CSRF lorsque l'application repose sur l'authentification sans état (en utilisant quelque chose comme HMAC)?
Exemple:
Nous avons une seule application de la page (sinon nous devons ajouter le jeton sur chaque lien:
<a href="...?token=xyz">...</a>.L'utilisateur s'authentifie en utilisant
POST /auth. En cas d'authentification réussie, le serveur renverra un jeton.Le jeton sera stocké via JavaScript dans une variable à l'intérieur de l'application à page unique.
Ce jeton sera utilisé pour accéder aux URL restreintes telles que
/admin.Le jeton sera toujours transmis à l'intérieur des en-têtes HTTP.
Il n'y a PAS de session Http et PAS de cookies.
Pour autant que je sache, il ne devrait (?!) Pas y avoir de possibilité d'utiliser des attaques intersites, car le navigateur ne stockera pas le jeton et ne peut donc pas l'envoyer automatiquement au serveur (c'est ce qui se passerait lors de l'utilisation de cookies / Session).
Est-ce que je manque quelque chose?
Réponses:
J'ai trouvé des informations sur CSRF + en n'utilisant aucun cookie pour l'authentification:
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
"puisque vous ne vous fiez pas aux cookies, vous n'avez pas besoin de vous protéger contre les requêtes intersites"
http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/
"Si nous suivons la voie des cookies, vous devez vraiment faire CSRF pour éviter les requêtes intersites. C'est quelque chose que nous pouvons oubliez lorsque vous utilisez JWT comme vous le verrez. "
(JWT = Json Web Token, une authentification basée sur des jetons pour les applications sans état)
http://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services
"Le moyen le plus simple de s'authentifier sans risquer les vulnérabilités CSRF est simplement d'éviter d'utiliser des cookies pour identifier l'utilisateur "
http://sitr.us/2011/08/26/cookies-are-bad-for-you.html
"Le plus gros problème avec CSRF est que les cookies ne fournissent absolument aucune défense contre ce type d'attaque. Si vous utilisez l'authentification par cookie vous devez également utiliser des mesures supplémentaires pour vous protéger contre la CSRF. La précaution la plus élémentaire que vous pouvez prendre est de vous assurer que votre application n'effectue jamais d'effets secondaires en réponse aux requêtes GET. "
Il y a beaucoup plus de pages, qui indiquent que vous n'avez pas besoin de protection CSRF, si vous n'utilisez pas de cookies pour l'authentification. Bien sûr, vous pouvez toujours utiliser des cookies pour tout le reste, mais évitez de stocker quoi que ce soit comme à l'
session_idintérieur.Si vous devez vous souvenir de l'utilisateur, il existe 2 options:
localStorage: Un magasin de valeurs-clés dans le navigateur. Les données stockées seront disponibles même après que l'utilisateur ferme la fenêtre du navigateur. Les données ne sont pas accessibles par d'autres sites Web, car chaque site dispose de son propre stockage.sessionStorage: Également un magasin de données dans le navigateur. La différence est la suivante: les données sont supprimées lorsque l'utilisateur ferme la fenêtre du navigateur. Mais cela reste utile si votre webapp se compose de plusieurs pages. Vous pouvez donc faire ce qui suit:sessionStoragesessionStoragesessionStorageou attendre que l'utilisateur ferme la fenêtre du navigateur, ce qui effacera toutes les données stockées.(pour les deux, regardez ici: http://www.w3schools.com/html/html5_webstorage.asp )
Existe-t-il des normes officielles pour l'authentification des jetons?
JWT (Json Web Token): Je pense que c'est encore un brouillon, mais il est déjà utilisé par de nombreuses personnes et le concept semble simple et sécurisé. (IETF: http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-25 )
Il existe également des bibliothèques pour de nombreux frameworks disponibles. Juste google pour ça!
la source
http://.../someRestResource?method=POST. Il s'agit donc essentiellement d'uneGETrequête, mais l'application serveur l'interprète comme unePOSTrequête, car elle a été configurée pour utiliser lemethodparamètre au lieu de l'en-tête HTTP....En ce qui concerne les navigateurs Web courants, ils appliquent la politique de même origine et n'exécuteront que lesGETdemandes adressées aux serveurs étrangers. Bien qu'il pourrait être possible d'exécuter lesPOSTrequêtes si le navigateur Web ne concerne pas les standards du Web (bug, les logiciels malveillants).Server Side App: Il n'est toujours pas possible d'envoyer un corps de requête, car les navigateurs courants ne le permettent pas. Cependant, si l'application serveur le permetmethod=POST, elle peut également permettrebody={someJson}de remplacer le corps de la demande par défaut. C'est vraiment une mauvaise conception d'API et extrêmement risquée. Cependant, si votre application serveur le permet,http://...?method=POST&body={someJson}vous devriez vraiment réfléchir à ce que vous avez fait là-bas et pourquoi et si cela est nécessaire du tout. (Je dirais que dans 99 9999% des cas, ce n'est pas nécessaire). De plus, les navigateurs ne peuvent envoyer que quelques kilo-octets de cette manière.TL; DR
Un JWT, s'il est utilisé sans cookies, élimine le besoin d'un jeton CSRF - MAIS! en stockant JWT dans session / localStorage, vous exposez votre JWT et l'identité de l'utilisateur si votre site présente une vulnérabilité XSS (assez courante). Il est préférable d'ajouter une
csrfTokenclé de JWT et de stocker le JWT dans un cookie avecsecureethttp-onlyattributs définis.Lisez cet article avec une bonne description pour plus d'informations https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
Vous devrez donc stocker le csrfToken dans localStorage / sessionStorage ainsi que dans le JWT lui-même (qui est stocké dans un cookie http uniquement et sécurisé). Ensuite, pour la protection csrf, vérifiez que le jeton csrf dans le JWT correspond à l'en-tête csrf-token soumis.
la source