Comprendre le jeton d'authenticité Rails

Question

Je suis confronté à quelques problèmes concernant Authenticity Token in rails, comme je l'ai fait plusieurs fois maintenant. Mais je ne veux pas vraiment résoudre ce problème et continuer, je voudrais vraiment comprendre le jeton Authenticité. Eh bien, ma question est, avez-vous une source complète d'informations sur ce sujet ou passer votre temps à expliquer dans les détails ici?

C'est ma dernière ressource avant d'aller au code source :-)

Answer 1

Ce qui se passe

Lorsque l'utilisateur affiche un formulaire pour créer, mettre à jour, ou de détruire une ressource, l'application Rails crée un random authenticity_token, les magasins de ce jeton dans la session, et le place dans un champ caché dans le formulaire. Lorsque l'utilisateur soumet le formulaire, Rails de recherche de l' authenticity_token, le compare à celui stocké dans la session, et si elles correspondent à la demande est autorisé à continuer.

Pourquoi ça arrive

Depuis l'authenticité jeton est stocké dans la session, le client ne peut pas connaître sa valeur. Cela empêche les gens de soumettre des formulaires à une application Rails, sans affichage de la forme à l'intérieur de l'application elle-même. Imaginez que vous utilisez Un service, vous vous êtes connecté dans le service et tout est ok. Maintenant, imaginez que vous êtes allé à l'utilisation du service de B, et que vous avez vu une image qui vous plaît, et appuyé sur l'image pour afficher une taille plus grande. Maintenant, si un mauvais code est là au service de B, il peut envoyer une demande de service (que vous êtes connecté), et demander la suppression de votre compte, en envoyant une demande à l' http://serviceA.com/close_account. C'est ce qui est connu comme CSRF (Cross Site Request Forgery).

Si Un service est l'aide de l'authenticité des jetons, ce vecteur d'attaque n'est plus applicable, car la demande de service B ne contient pas le bon authenticité jeton, et ne sera pas autorisé à continuer.

Notes

Gardez à l'esprit, Rails seuls les chèques POST, PUT et DELETE demandes. OBTENIR la demande ne sont pas vérifié l'authenticité de jeton. Pourquoi? parce que la spécification HTTP états qui OBTIENNENT les demandes doivent pas créer, modifier ou détruire des ressources au niveau du serveur, et la demande doit être idempotent (si vous exécutez la même commande à plusieurs reprises, vous devriez obtenir le même résultat à chaque fois).

Leçons

Utiliser authenticity_token afin de protéger vos POST, PUT et DELETE demandes. Assurez-vous également de ne pas permettre à toute demande qui pourrait potentiellement modifier les ressources sur le serveur.

---

EDIT: Vérifiez le commentaire de @erturne concernant des demandes d'être idempotent. Il l'explique dans une meilleure façon que j'ai fait ici.

Answer 2

L'authenticité jeton est conçu de sorte que vous savez que votre demande est transmise à partir de votre site web. Il est généré à partir de la machine sur laquelle il s'exécute avec un identifiant unique que seul votre machine peut savoir, aidant ainsi à prévenir le cross-site request forgery attaques.

Si vous êtes tout simplement avoir de la difficulté avec les rails de nier votre script AJAX d'accès, vous pouvez utiliser

<%= form_authenticity_token %>

pour générer le jeton correct lors de la création de votre formulaire.

Vous pouvez en lire plus à ce sujet dans la documentation.

Answer 3

L'Authenticité Jeton est un moyen de lutter contre Cross-Site Request Forgery (CSRF). Qu'est-ce que CSRF, vous demandez-vous?

C'est une façon permettant à un attaquant de détourner les séances, sans même en connaître les jetons de session.

Scénario:

• Visitez le site de votre banque, connectez-vous.
• Puis visite de l'attaquant du site (par exemple, parrainé annonces de confiance de l'organisation).
• Page de l'attaquant comprend le formulaire avec les mêmes champs que la banque "Transfert de Fonds".
• Attaquant connaît informations de votre compte, et a pré-rempli les champs du formulaire de transférer de l'argent à partir de votre compte attaquant du compte.
• Page de l'attaquant comprend Javascript qui transmet le formulaire à votre banque.
• Lorsque le formulaire est soumis, navigateur inclut vos cookies pour le site de la banque, y compris le jeton de session.
• Banque transfère de l'argent sur l'attaquant du compte.
• Le formulaire peut être dans un iframe qui est invisible, de sorte que vous ne savez jamais l'attaque s'est produite.
• Ceci est appelé Cross-Site Request Forgery (CSRF).

CSRF solution:

• Serveur pouvez marquer les formes qui sont venus à partir du serveur lui-même
• Chaque formulaire doit contenir un supplément de jeton d'authentification comme un champ caché.
• Jeton doit être imprévisible (attaquant peut pas le deviner).
• Le serveur fournit un jeton valide dans des formes dans ses pages.
• Serveur vérifie jeton lorsque formulaire posté, rejette les formes sans jeton.
• Exemple de jeton: identifiant de session chiffrée avec le serveur de clé secrète.
• Rails génère automatiquement ces jetons: voir le authenticity_token champ de saisie dans chaque formulaire.

Answer 4

L' Authenticity Token est de rails méthode pour prévenir "cross-site request forgery (CSRF ou XSRF) attaques.

Pour faire simple, il permet de s'assurer que le PUT / POST / DELETE (méthodes qui peuvent modifier le contenu) les demandes de votre application web sont fabriqués à partir du navigateur du client et non plus d'un tiers (attaquant) qui a accès à un cookie créé sur le côté client.

Answer 5

depuis Authenticity Token est si important, et dans Rails 3.0+, vous pouvez utiliser

  <%= token_tag nil %>
 

créer

 <input name="authenticity_token" type="hidden" value="token_value">
 

nulle part