26-03-2010, 01:22 PM
Cela devrait être fait pour toutes les requêtes d'actions (donc les méthodes HTTP Post, Put et Delete).
A chaque fois que le serveur rend une page, tu lui fais générer une chaîne aléatoire : ce sera ton jeton (token).
Tu stockes cette chaîne dans la session du visiteur et tu l'envoie dans les requêtes d'actions (grâce à un champ caché).
Sur la page de traitement, tu compares le jeton en session à celui transmis dans la requête.
Ainsi, ça te garantit que l'utilisateur est passé par le formulaire (et qu'il n'a pas cliqué sur un lien). C'est une contremesure courante aux attaques CSRF.
Exemple : si je sais que tu es administrateur du site Lambda, je t'envoie un lien (TinyURL par exemple) qui t'envoie sur lambda.tld/admin/delete_user.php?id=23. Hop j'ai gagné, tu as supprimé l'utilisateur 23 toi même ! Ça implique de deviner certaines choses, mais quand tu sécurises, il faut penser que rien n'est secret et faire un test dit full knowledge.
Ensuite, quand on utilise Ajax, il faut transmettre ce token à Javascript. Pour cela, il y a plusieurs moyens. Une variable Javascript globale, mais c'est crade. Le plus propre reste à mon sens de s'inspirer Rails 3 et de déclarer une balise méta :
Ainsi, dans tes requêtes Ajax, tu as juste à récupérer le couple (nom du paramètre; token) et l'injecter dans ta requête. C'est trivial et propre.
Enfin, comme toujours (vraiment toujours), de bons développeurs ont déjà pensé à ça avant vous et ont mis au point des solutions propres et sûres. Encore du temps gagné à utiliser un bon framework, où tout cela se fait automatiquement.
Sephi-Chan
A chaque fois que le serveur rend une page, tu lui fais générer une chaîne aléatoire : ce sera ton jeton (token).
Tu stockes cette chaîne dans la session du visiteur et tu l'envoie dans les requêtes d'actions (grâce à un champ caché).
Sur la page de traitement, tu compares le jeton en session à celui transmis dans la requête.
Ainsi, ça te garantit que l'utilisateur est passé par le formulaire (et qu'il n'a pas cliqué sur un lien). C'est une contremesure courante aux attaques CSRF.
Exemple : si je sais que tu es administrateur du site Lambda, je t'envoie un lien (TinyURL par exemple) qui t'envoie sur lambda.tld/admin/delete_user.php?id=23. Hop j'ai gagné, tu as supprimé l'utilisateur 23 toi même ! Ça implique de deviner certaines choses, mais quand tu sécurises, il faut penser que rien n'est secret et faire un test dit full knowledge.
Ensuite, quand on utilise Ajax, il faut transmettre ce token à Javascript. Pour cela, il y a plusieurs moyens. Une variable Javascript globale, mais c'est crade. Le plus propre reste à mon sens de s'inspirer Rails 3 et de déclarer une balise méta :
<meta name="csrf-token" content="ton_token" />
<meta name="csrf-param" content="authenticity_token" />
Ainsi, dans tes requêtes Ajax, tu as juste à récupérer le couple (nom du paramètre; token) et l'injecter dans ta requête. C'est trivial et propre.
Enfin, comme toujours (vraiment toujours), de bons développeurs ont déjà pensé à ça avant vous et ont mis au point des solutions propres et sûres. Encore du temps gagné à utiliser un bon framework, où tout cela se fait automatiquement.
Sephi-Chan