Une astuce pour se protéger des attaques CSRF
mardi 20 janvier 2004 :: perrick :: PHP :: 2 commentaires :: aucun trackbackC'est dans l'article en ligne du dernier Direction | PHP que je viens de trouver une astuce intéressante pour se protéger des attaques CSRF. Tout d'abord une définition : CSRF = Cross-Site Request Forgeries, il s'agit d'une attaque par simulation de requête HTTP.
Ensuite extrait de l'article : Obligez l’utilisateur à utiliser vos formulaires HTML.
Mes techniques préférées sont celles qui impliquent un secret partagé entre le serveur et l’utilisateur légitime. [...] A chaque fois qu’un utilisateur demande un formulaire, une nouvelle marque est générée et cette marque est sauvegardée sur le serveur (dans la session de l’utilisateur, remplaçant les précédentes) et incluse dans le formulaire comme une variable cachée du formulaire. Ainsi, quand un message est posté, non seulement la marque est comparée à celle de la session de l’utilisateur, mais un temps mort peut également être appliqué pour minimiser davantage le risque.Le reste de l'article est aussi très intéressant pour ceux qui ne sont pas encore familiers de "sécurité en applications webs". Et l'auteur -- Chris Shiflett -- écrit d'autres choses : un livre, HTTP Developer's Handbook, et un blog que j'ai ajouté à ma liste personnel.
Vos commentaires et/ou trackbacks
Le mercredi 21 janvier 2004 à 10:49, commentaire par Eric Daspet :: #
Le concept même de ces "protections" est bancale. Pour faire un comparatif ça me rappelle un projet où le développeur initial voulait "interdire" aux utilisateurs d'arriver directement sur l'URL de la popup et les forcer pour ça à cliquer sur un lien de la page.
Que ce soit dans le cas de ma popup ou dans le cas du formulaire il s'agit simplement d'une mauvaise catégorisation entre privé et public.
Soit l'information est réellement publique et dans ce cas il n'y a pas lieu de faire de différence entre une requête faite manuellement sur un navigateur classique et une requête qui tombre sous sa définition de CSRF (quel est le dommage ? de toutes façons l'info est publique)
Soit l'info est privée/réservée/filtrée et dans ce cas on a un modèle d'authentification classique.
Le simple fait de parler de "simuler une requête HTTP" est significatif : on ne simule pas une requête HTTP, on la fait. On la fait à la main ou par script plutôt que par le navigateur mais elle est tout aussi valable.
Ne cédez pas à la tentation de vouloir controler comment le client accède à l'information, contentez vous de vérifier au votre information est publique ou que l'utilisateur s'est authentifié avec un login adéquat. Tout le reste, c'est à dire qu'il utilise un navigateur ou pas, que la requete soit automatisée ou pas, etc. ne devrait pas intervenir.
Surtout que bon, vous croyez vraiment que un script ne peut pas lire la marque dans le formulaire afin de la prendre en compte dans sa requête suivante ? si un navigateur peut le faire alors autre chose pourra aussi.
Le vendredi 23 janvier 2004 à 14:48, commentaire par pk :: site :: #
Toujours au niveau de la sécurité d'une application, un article sur ONLamp.com propose un proxy en PHP qui permet de modifier à la volée des requêtes HTTP GET ou (et c'est là que c'est intéressant) POST : www.onlamp.com/pub/a/php/...
Ajouter un commentaire
Les commentaires pour ce billet sont fermés.