Jeton CSRF nécessaire lors de l'utilisation de l'authentification sans état (= sans session)?

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?

J'ai trouvé des informations sur CSRF + en n'utilisant aucun cookie pour l'authentification:

1. 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"

2. 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)

3. 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 "

4. 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:

1. 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.

2. 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:

   • L'utilisateur se connecte, puis vous stockez le jeton dans sessionStorage
   • L'utilisateur clique sur un lien, qui charge une nouvelle page (= un lien réel , et pas de remplacement de contenu javascript)
   • Vous pouvez toujours accéder au jeton depuis sessionStorage
   • Pour vous déconnecter, vous pouvez supprimer manuellement le jeton sessionStorageou 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!

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 avec secureet http-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 pouvez rendre cette protection CSRF sans état en incluant une revendication xsrfToken JWT:

{ "iss": "http://galaxies.com", "exp": 1300819380, "scopes": ["explorer", "solar-harvester", "seller"], "sub": "tom@andromeda.com", "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e" }

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.