Jeton CSRF nécessaire lors de l'utilisation de L'authentification sans état(= Sessionless)?
Est-il nécessaire d'utiliser la Protection CSRF lorsque l'application repose sur une authentification sans état (en utilisant quelque chose comme HMAC)?
Exemple:
Nous avons une application à une seule 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 retournera un jeton.Le jeton sera stocké via JavaScript dans une variable à l'intérieur de la seule page App.
Ce jeton sera utilisé pour accéder à des URL restreintes comme
/admin.Le jeton sera toujours transmis dans les en-têtes HTTP.
Il N'y a pas de Session Http, et pas de Cookies.
Pour autant que je comprends, il devrait(?!) il n'y a aucune possibilité d'utiliser des attaques inter-sites, car le navigateur ne stockera pas le jeton, et donc il ne peut pas l'envoyer automatiquement au serveur (c'est ce qui se passerait lors de l'utilisation Cookies De Session).
Est-ce que je manque quelque chose?
2 réponses
J'ai trouvé des informations sur CSRF + en utilisant NON cookies pour l'authentification:
-
Https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
"puisque vous ne comptez pas sur les cookies, vous n'avez pas besoin de vous protéger contre les demandes inter-sites" Http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/
"Si nous descendons le chemin des cookies, vous devez vraiment faire CSRF pour éviter le site croisé demande. C'est quelque chose que nous pouvons oublier en utilisant JWT comme vous le verrez."
(JWT = JSON Web Token, une authentification basée sur un jeton pour les applications sans état)Http://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services
"La façon la plus simple de faire l'authentification sans risquer les vulnérabilités CSRF est d'éviter simplement d'utiliser des cookies pour identifier le 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 des cookies, vous devez également utiliser des mesures supplémentaires pour vous protéger contre CSRF. La précaution la plus fondamentale que vous pouvez prendre est de vous assurer que votre application n'effectue jamais d'effets secondaires en réponse aux demandes GET."
Il y en 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 stocker quelque chose comme session_id à l'intérieur.
Si vous devez vous souvenir de l'utilisateur, il y a 2 options:
localStorage: un magasin de clé-valeur 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 espace de stockage.-
sessionStorage: aussi 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 il est toujours utile, si votre webapp se compose de plusieurs pages. Donc, vous pouvez 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 aucun contenu javascript-replace)
- Vous pouvez toujours accéder au jeton de
sessionStorage - pour vous déconnecter, vous pouvez supprimer manuellement le jeton de
sessionStorageou attendre que l'utilisateur ferme la fenêtre du navigateur, ce qui effacera toutes les données stockées.
- l'utilisateur se connecte, puis vous stockez le jeton dans
(pour les deux, jetez un oeil ici: http://www.w3schools.com/html/html5_webstorage.asp )
Existe-t-il des normes officielles pour l'authentification par jeton?
JWT (JSON Web Token): je pense que c'est toujours un brouillon, mais il est déjà utilisé par beaucoup de gens 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 beaucoup de framework disponibles. Juste google pour cela!
TL; DR
Un JWT, s'il est utilisé sans Cookies, annule 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 a une vulnérabilité XSS (assez courante). Il est préférable d'ajouter une clé csrfToken au JWT et de stocker le JWT dans un cookie avec les attributs secure et http-only définis.
Lisez cet article avec une bonne description pour en savoir plus info 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 JWT xsrfToken:
{ "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.