- le token doit être unique au formulaire, là il semble que le token ne change jamais une fois qu'il est mis en cookie
- pourquoi mettre le token en cookie ?! c'est ajouter une vulnérabilité possible au machin, et ça ne sert strictement à rien
- le token ne semble pas être stocké sur le serveur, ne laissant aucun moyen de vérifier la requête indépendamment du client, résultat (et explication du pourquoi de la vérif de Referer), n'importe qui peut forger le champ envoyé en POST *et* le cookie
Ce mécanisme bancal ne devrait jamais être utilisé, il ne protège que de manière marginale contre les attaques CSRF, et de plus rajoute de nombreux problèmes de compatibilités client (obligation d'accepter les cookies, d'envoyer un header HTTP Referer valide, etc.). Et une règle simple : on n'utilise jamais le stockage du client pour vérifier que le client fait bien les choses, et ici c'est le cas ! Se baser sur un cookie c'est vraiment une ineptie...
Bref un seul conseil : n'utilise pas ce truc horrible, je n'ai jamais vu une solution aussi mal pensée.
Pour se protéger des CSRF, une solution simple :
- générer un token unique pour chaque formulaire (et non le même pour tous les formulaires !)
- le stocker au niveau du serveur (par exemple dans une session associée au client, mais ça peut aussi être associé à un identifiant unique du formulaire)
- le mettre dans un champ hidden dans le formulaire
- vérifier à l'exécution de l'action que le champ envoyé correspond à ce qui est stocké sur le *serveur* (qui est de confiance, qu'on maîtrise, contrairement à ce qu'envoie le client)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: et les logs/pass pour tester
Posté par BohwaZ (site web personnel, Mastodon) . En réponse au journal Lancement de la bêta de Ma Petite Auto Entreprise. Évalué à 5.
- le token doit être unique au formulaire, là il semble que le token ne change jamais une fois qu'il est mis en cookie
- pourquoi mettre le token en cookie ?! c'est ajouter une vulnérabilité possible au machin, et ça ne sert strictement à rien
- le token ne semble pas être stocké sur le serveur, ne laissant aucun moyen de vérifier la requête indépendamment du client, résultat (et explication du pourquoi de la vérif de Referer), n'importe qui peut forger le champ envoyé en POST *et* le cookie
Ce mécanisme bancal ne devrait jamais être utilisé, il ne protège que de manière marginale contre les attaques CSRF, et de plus rajoute de nombreux problèmes de compatibilités client (obligation d'accepter les cookies, d'envoyer un header HTTP Referer valide, etc.). Et une règle simple : on n'utilise jamais le stockage du client pour vérifier que le client fait bien les choses, et ici c'est le cas ! Se baser sur un cookie c'est vraiment une ineptie...
Bref un seul conseil : n'utilise pas ce truc horrible, je n'ai jamais vu une solution aussi mal pensée.
Pour se protéger des CSRF, une solution simple :
- générer un token unique pour chaque formulaire (et non le même pour tous les formulaires !)
- le stocker au niveau du serveur (par exemple dans une session associée au client, mais ça peut aussi être associé à un identifiant unique du formulaire)
- le mettre dans un champ hidden dans le formulaire
- vérifier à l'exécution de l'action que le champ envoyé correspond à ce qui est stocké sur le *serveur* (qui est de confiance, qu'on maîtrise, contrairement à ce qu'envoie le client)
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)